R: R: [Serusers] SER -> PSTN Gateway+NAT: BYE handling problem

Greger V. Teigre greger at teigre.com
Tue Mar 20 20:43:18 CET 2007


Thanks for the detailed trace, I wouldn't have spent on this without it ;-)

Its' the ACK for the OK that is not done fix_nated_contact for. In fact, 
checking the getting started rtpproxy file, it seems that this error is 
also found there. All messages coming from behind NAT should have the 
contact fixed.
Strictly speaking, RFC3261 states that the dialog state should be 
created from the information found in the INVITE, not the ACK on an OK. 
Your BYE generating entity does this error. I have seen this problem 
before, but has not really thought about it from the getting started 
config file perspective.
It is thus safer to change Contact on ALL messages behind NAT, 
regardless of they are loose routed or not.
g-)

Fabio Macchi wrote:
>
> Hi Greger,
>
>  
>
> I attached an ethereal SIP call trace of a test call ( summary and 
> detailed, I simple maskerade final ip numbers ): below only the INVITE 
> relayed from proxy to gateway:
>
>  
>
> Session Initiation Protocol
>
>     Request-Line: INVITE sip:9999001234 at 194.244.gatewayIP:5060 SIP/2.0
>
>         Method: INVITE
>
>         [Resent Packet: False]
>
>     Message Header
>
>         Record-Route: <sip:194.244.Proxy__IP;ftag=12e1e2e19d527792;lr=on>
>
>         Via: SIP/2.0/UDP 194.244.Proxy__IP;branch=z9hG4bKb24f.5133a2c4.0
>
>             Transport: UDP
>
>             Sent-by Address: 194.244.Proxy__IP
>
>             Branch: z9hG4bKb24f.5133a2c4.0
>
>         Via: SIP/2.0/UDP 
> 1.255.ua_priv__IP;rport=1176;received=213.156.ua_pub_IP;branch=z9hG4bK35ca7adf63e3094f
>
>             Transport: UDP
>
>             Sent-by Address: 1.255.ua_priv__IP
>
>             RPort: 1176
>
>             Received: 213.156.ua_pub_IP
>
>             Branch: z9hG4bK35ca7adf63e3094f
>
>         From: "000003" <sip:000003 at 194.244.Proxy__IP>;tag=12e1e2e19d527792
>
>             SIP Display info: "000003"
>
>             SIP from address: sip:000003 at 194.244.Proxy__IP
>
>             SIP tag: 12e1e2e19d527792
>
>         To: <sip:9999001234 at 194.244.Proxy__IP>
>
>             SIP to address: sip:9999001234 at 194.244.Proxy__IP
>
>         Contact: <sip:000003 at 213.156.ua_pub_IP:1176>
>
>             Contact Binding: <sip:000003 at 213.156.ua_pub_IP:1176>
>
>                 URI: <sip:000003 at 213.156.ua_pub_IP:1176>
>
>                     SIP contact address: sip:000003 at 213.156.ua_pub_IP:1176
>
>         Supported: replaces
>
>         Call-ID: 953e8996cfcc4ccc at 1.255.ua_priv__IP
>
>         CSeq: 60577 INVITE
>
>             Sequence Number: 60577
>
>             Method: INVITE
>
>         User-Agent: Grandstream HT386 1.0.3.64 FXS0
>
>         Max-Forwards: 16
>
>         Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE
>
>         Content-Type: application/sdp
>
>         Content-Length: 327
>
>     Message body
>
>  
>
> As you can see, contact informations are correctly fixed with the 
> pubblic UA address, but when the callee hungs up, the BYE is relayed 
> to the private IP address: am I missing something ?
>
> In this invite I see UA private address only in VIA: does BYE look to 
> this parameter ?
>
> Later caller hangs up too, and the OK is relayed to the correct IP/port.
>
>  
>
> Any help would be high appreciate, thanks in advance.
>
>  
>
> Fabio
>
>  
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20070320/28a0870f/attachment.htm>


More information about the sr-users mailing list