[Asterisk-Users] chan_sip changes affecting ACK? - Bug?

[Chad Brown]

Are there any changes to chan_sip since 09/16/04 in the stable branch
that could affect the way Asterisk issues an ACK? 

 

The reason I ask...I have a product by INGATE called the Siparator which
assists in NAT traversal. It worked great until I upgraded to Asterisk
v1.0. After comparing the logs it looks like asterisk may no longer send
the GUID type ACK response the Siparator is expecting. Take a quick look
at the difference below. (BTW 10.10.0.6 is the Asterisk box)

 

Asterisk build from 09/16/04: (These are examples not necessarily the
same call)

 

Siparator log says:

>>> Info: sipfw: recv from 10.10.0.6: ACK
sip:e_RY4_466QliT14zp26IqP6KYbo9s6ZERZM0fQuq8nzGMs71r0jwT2UOVGyjPobFW at 10
.10.0.5 SIP/2.0

 

Asterisk sip debug says:

Transmitting:

ACK
sip:eKvj1A8MZuPxroET_BXewOVi3uR-3Ad_liBBCrJQq8dbq7VO-p-RGl6icEsXi2TZX at 10
.10.0.5 SIP/2.0

Via: SIP/2.0/UDP 10.10.0.6:5060;branch=z9hG4bK4441b7b5

Route:
<sip:eKvj1A8MZuPxroET_BXewOVi3uR-3Ad_liBBCrJQq8dbq7VO-p-RGl6icEsXi2TZX at 1
0.10.0.5>

From: "Chad Brown" <sip:asterisk at 10.10.0.6>;tag=as490d60cd

To: <sip:12534056726 at 10.10.0.5>;tag=3307489924-529483

Contact: <sip:asterisk at 10.10.0.6>

Call-ID: 08b25b4e793c9fda031a818f7922c61a at 10.10.0.6

CSeq: 102 ACK

User-Agent: Asterisk PBX

Content-Length: 0

 

 

 

Asterisk build v1.0 (These are examples not necessarily the same call)

 

Siparator log says:

>>> Info: sipfw: recv from 10.10.0.6: ACK sip:12534056726 at 10.10.0.5
SIP/2.0

 

Asterisk sip debug says:

Transmitting:

ACK sip:12534056726 at 10.10.0.5 SIP/2.0

Via: SIP/2.0/UDP 10.10.0.6:5060;branch=z9hG4bK4be3d57b

Route:
<sip:eDXTNO6dkwsoA4_uBoSao6QR6sGzyTc9suJBrvzuYOVHclaWI7YmOtc3aQUmYltVy at 1
0.10.0.5>

From: "Chad Brown" <sip:asterisk at 10.10.0.6>;tag=as5c7a2a79

To: <sip:12534056726 at 10.10.0.5>;tag=3307285355-806590

Contact: <sip:asterisk at 10.10.0.6>

Call-ID: 29fbc7297c33271446d86cfc474d0b75 at 10.10.0.6

CSeq: 102 ACK

User-Agent: Asterisk PBX

Content-Length: 0

 

 

My guess is that the Siparator keeps track of separate streams with the
long GUID string and then does an appropriate transform. Since the GUID
is gone in v1.0 so is Siparators ability to translate/transform the
call.

 

Thanks for you help!

 

Chad Brown - IdentityMine

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20041022/e0553a23/attachment.htm