[ previous ] [ next ] [ threads ]
 To :  yate@v...
 From :  Paul Chitescu <paulc@v...>
 Subject :  Re: [yate] SDP rewriting/ignoring problem
 Date :  Mon, 31 May 2010 12:16:46 +0300
Hi!

Yate displays exactly what it receives so if there's a difference it is caused 
by something in between - the usual culprit being a SIP Application Level 
Gateway.

-INVITE sip:40215697951@8...:5060 SIP/2.0
+INVITE sip:40215697951@1...:5060 SIP/2.0

-c=IN IP4 193.16.148.226
+c=IN IP4 193.16.148.244

Since there is no extra Via header this excludes a SIP proxy doing the 
changes.

Please check your network, find and disable the ALG, most of them are nothing 
but trouble.

http://www.voip-info.org/wiki/view/Routers+SIP+ALG

Regards,

Paul


On Monday 31 May 2010 12:22:25 am Radu - Eosif Mihailescu wrote:
> Hello list,
> 
> I have encountered the following problem while using Yate as a SIP PBX 
> in conjunction with a well known local SIP provider that uses two 
> different hosts for signalling (SIP/SDP) and media (RTP): Yate seems to 
> ignore the differing address and attempts to open a RTP session with the 
> signalling host -- which obviously fails.
> 
> This is how the packet in question looks like if you ask yate: {
>  Received 1113 bytes SIP message from 193.16.148.244:5060
> ------
> INVITE sip:40215697951@1...:5060 SIP/2.0
> Record-Route: 
> Via: SIP/2.0/UDP 
> 193.16.148.244;branch=z9hG4bK340b.3784c6f6faf69d14f72a0f9c9f6beaba.0
> Via: SIP/2.0/UDP 
> 
193.16.148.244:5061;branch=z9hG4bK6012d095c862be98b3ec66dcbc7c20cb;rport=5061
> Max-Forwards: 16
> From: ;tag=6262e281464926ced47061945b8c1b68
> To: 
> Call-ID: 90AD75FA-6B6511DF-BA12DF22-33814A24@1...
> CSeq: 200 INVITE
> Contact: Anonymous 
> Expires: 300
> User-Agent: Sippy
> cisco-GUID: 2426407105-1801785823-3109552129-1119049838
> h323-conf-id: 2426407105-1801785823-3109552129-1119049838
> Content-disposition: session
> Content-Length: 311
> Content-Type: application/sdp
> 
> v=0
> o=Sippy 476310796 0 IN IP4 193.16.148.244
> s=SIP Call
> t=0 0
> m=audio 17112 RTP/AVP 8 0 3 18 101
> *c=IN IP4 193.16.148.244*
> a=rtpmap:8 PCMA/8000
> a=rtpmap:0 PCMU/8000
> a=rtpmap:3 GSM/8000
> a=rtpmap:18 G729/8000
> a=fmtp:18 annexb=yes
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-16
> a=direction:passive
> ------
> }
> 
> This is how the same packet looks like if you ask tcpdump/wireshark: {
> INVITE sip:40215697951@8...:5060 SIP/2.0
> Record-Route: 
> Via: SIP/2.0/UDP 
> 193.16.148.244;branch=z9hG4bK340b.3784c6f6faf69d14f72a0f9c9f6beaba.0
> Via: SIP/2.0/UDP 
> 
193.16.148.244:5061;branch=z9hG4bK6012d095c862be98b3ec66dcbc7c20cb;rport=5061
> Max-Forwards: 16
> From: ;tag=6262e281464926ced47061945b8c1b68
> To: 
> Call-ID: 90AD75FA-6B6511DF-BA12DF22-33814A24@1...
> CSeq: 200 INVITE
> Contact: Anonymous 
> Expires: 300
> User-Agent: Sippy
> cisco-GUID: 2426407105-1801785823-3109552129-1119049838
> h323-conf-id: 2426407105-1801785823-3109552129-1119049838
> Content-disposition: session
> Content-Length: 311
> Content-Type: application/sdp
> 
> v=0
> o=Sippy 476310796 0 IN IP4 193.16.148.244
> s=SIP Call
> t=0 0
> m=audio 17112 RTP/AVP 8 0 3 18 101
> *c=IN IP4 193.16.148.226*
> a=rtpmap:8 PCMA/8000
> a=rtpmap:0 PCMU/8000
> a=rtpmap:3 GSM/8000
> a=rtpmap:18 G729/8000
> a=fmtp:18 annexb=yes
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-16
> a=direction:passive
> }
> 
> I'm using Yate SVN r3342 on CentOS 5.5 i386.
> 
> If you need any additional information regarding this issue, I would be 
> happy to provide it on request.
> 
> Thank you for your time,
> Radu - Eosif Mihailescu
> 
> -- 
> @Dexter  GSM: +40 (721) 294400
> JID: csdexter@j... ICQ: 27762040 Y!: csdexter
> MSN: rmihailescu@h... AIM: csdexter Skype: csdexter
> Blog: http://www.linux360.ro/~csdexter/blog/