Hi Thamer, actually I see a 408 TIMEOUT for the second re-INVITE - but I see not outgoing re-INVITE in the second step (only the inbound message)
Looking at the 2 re-INVITEs, I would say you have a routing issue as the first re-INVITE has as RURI a public IP (sip:[email protected]:5060), while the second re-INVITE has a private IP (sip:[email protected]:5060) So, maybe the NAT traversal logic for the sequential requests is not correct. Regards, Bogdan Thamer Alharbash wrote: > Hi Bogdan, > > Sorry for not getting back sooner. I've updated my config a bit. I'm > including what our reinvite handling looks like and the two reinvites > that pass through opensips. The second one as you can see has no > payload (ngrep shows ...) I have verified this as well under wireshark. > > if (has_totag()) { > > # sequential request within a dialog should > # take the path determined by record-routing > > if (loose_route()) { > > if (is_method("BYE")) { > setflag(1); # do accounting ... > setflag(3); # ... even if the > transaction fails > > } else if (is_method("INVITE")) { > # even if in most of the cases is > useless, do RR for > # re-INVITEs also, as some buggy > clients do change route set > # during the dialog. > record_route_preset > ("proxy.ip.address.here"); > } > # route it out to whatever destination was > set by loose_route() > # in $du (destination URI). > route(1); > ... > route[1] { > # for INVITEs enable some additional helper routes > if (is_method("INVITE")) { > t_on_branch("1"); > t_on_reply("1"); > t_on_failure("1"); > if(has_body("application/sdp")) { > rtpproxy_offer("frc","proxy.ip.address.here"); > xlog ("Setting rtpproxy_offer"); > } > if (isbflagset(6)) { > fix_nated_contact(); > } > > } > > > > > -- FIRST REINVITE > > U carrier.ip.address.here:5060 -> our.proxy.ip.address:5060 > INVITE sip:[email protected]:5060;transport=udp;user=phone SIP/ > 2.0. > Via: SIP/2.0/UDP carrier.ip.address.here: > 5060;branch=z9hG4bK2kspjh305gqgrfskk5s0sbk9m0g10.1. > Call-ID: [email protected]. > From: <sip: > [email protected];user=phone>;tag=SD1ko0299-324092c7 > +1+ad440023+8233f214. > To: "Thamer Al-Harbash" <sip: > [email protected];user=phone>;tag=83134be1983195b6. > CSeq: 878247939 INVITE. > Expires: 180. > Min-SE: 1800. > Session-Expires: 1800;refresher=uac. > Supported: 100rel,timer. > Max-Forwards: 69. > Contact: <sip:[email protected]:5060;transport=udp>. > Content-Type: application/sdp. > Content-Length: 216. > Route: <sip:carrier.ip.address.here;lr=on>. > . > v=0. > o=- 3474221042 3474221054 IN IP4 carrier.ip.address.here. > s=-. > c=IN IP4 carrier.ip.address.here. > t=0 0. > m=audio 10044 RTP/AVP 0 101. > a=sendrecv. > a=ptime:20. > a=rtpmap:0 PCMU/8000. > a=rtpmap:101 telephone-event/8000. > a=fmtp:101 0-15. > > > U our.proxy.ip.address:5060 -> carrier.ip.address.here:5060 > SIP/2.0 100 Giving a try. > Via: SIP/2.0/UDP carrier.ip.address.here: > 5060;branch=z9hG4bK2kspjh305gqgrfskk5s0sbk9m0g10.1. > Call-ID: [email protected]. > From: <sip: > [email protected];user=phone>;tag=SD1ko0299-324092c7 > +1+ad440023+8233f214. > To: "Thamer Al-Harbash" <sip: > [email protected];user=phone>;tag=83134be1983195b6. > CSeq: 878247939 INVITE. > Server: OpenSIPS (1.6.0-notls (i386/linux)). > Content-Length: 0. > . > > U our.proxy.ip.address:5060 -> uac.ip.address.here:5060 > INVITE sip:[email protected]:5060;transport=udp;user=phone SIP/ > 2.0. > Record-Route: <sip:our.proxy.ip.address;lr=on>. > Via: SIP/2.0/UDP our.proxy.ip.address;branch=z9hG4bK20d7.90192965.0. > Via: SIP/2.0/UDP carrier.ip.address.here: > 5060;branch=z9hG4bK2kspjh305gqgrfskk5s0sbk9m0g10.1. > Call-ID: [email protected]. > From: <sip: > [email protected];user=phone>;tag=SD1ko0299-324092c7 > +1+ad440023+8233f214. > To: "Thamer Al-Harbash" <sip: > [email protected];user=phone>;tag=83134be1983195b6. > CSeq: 878247939 INVITE. > Expires: 180. > Min-SE: 1800. > Session-Expires: 1800;refresher=uac. > Supported: 100rel,timer. > Max-Forwards: 68. > Contact: <sip:[email protected]:5060;transport=udp>. > Content-Type: application/sdp. > Content-Length: 217. > . > v=0. > o=- 3474221042 3474221054 IN IP4 carrier.ip.address.here. > s=-. > c=IN IP4 our.proxy.ip.address. > t=0 0. > m=audio 32104 RTP/AVP 0 101. > a=sendrecv. > a=ptime:20. > a=rtpmap:0 PCMU/8000. > a=rtpmap:101 telephone-event/8000. > a=fmtp:101 0-15. > > -- SECOND REINVITE > > U carrier.ip.address.here:5060 -> our.proxy.ip.address:5060 > INVITE sip:[email protected]:5060;transport=udp;user=phone SIP/2.0. > Via: SIP/2.0/UDP carrier.ip.address.here: > 5060;branch=z9hG4bK2kspjh305gqgrfskk5s0sbk9m0020.1. > Call-ID: [email protected]. > From: <sip: > [email protected];user=phone>;tag=SD1ko0299-324092c7 > +1+ad440023+8233f214. > To: "Thamer Al-Harbash" <sip: > [email protected];user=phone>;tag=83134be1983195b6. > CSeq: 878247940 INVITE. > Expires: 180. > Min-SE: 1800. > Session-Expires: 1800;refresher=uac. > Supported: 100rel,timer. > Max-Forwards: 69. > Contact: <sip:[email protected]:5060;transport=udp>. > Content-Type: application/sdp. > Content-Length: 216. > Route: <sip:our.proxy.ip.address;lr=on>. > . > v=0. > o=- 3474221042 3474221054 IN IP4 carrier.ip.address.here. > s=-. > c=IN IP4 carrier.ip.address.here. > t=0 0. > m=audio 10044 RTP/AVP 0 101. > a=sendrecv. > a=ptime:20. > a=rtpmap:0 PCMU/8000. > a=rtpmap:101 telephone-event/8000. > a=fmtp:101 0-15. > > > U our.proxy.ip.address:5060 -> carrier.ip.address.here:5060 > SIP/2.0 100 Giving a try. > Via: SIP/2.0/UDP carrier.ip.address.here: > 5060;branch=z9hG4bK2kspjh305gqgrfskk5s0sbk9m0020.1. > Call-ID: [email protected]. > From: <sip: > [email protected];user=phone>;tag=SD1ko0299-324092c7 > +1+ad440023+8233f214. > To: "Thamer Al-Harbash" <sip: > [email protected];user=phone>;tag=83134be1983195b6. > CSeq: 878247940 INVITE. > Server: OpenSIPS (1.6.0-notls (i386/linux)). > Content-Length: 0. > . > > > U our.proxy.ip.address:5060 -> uac.ip.address.here:5060 > .... > > U our.proxy.ip.address:5060 -> carrier.ip.address.here:5060 > SIP/2.0 408 Request Timeout. > Via: SIP/2.0/UDP carrier.ip.address.here: > 5060;branch=z9hG4bK2kspjh305gqgrfskk5s0sbk9m0020.1. > Call-ID: [email protected]. > From: <sip: > [email protected];user=phone>;tag=SD1ko0299-324092c7 > +1+ad440023+8233f214. > To: "Thamer Al-Harbash" <sip: > [email protected];user=phone>;tag=83134be1983195b6. > CSeq: 878247940 INVITE. > Server: OpenSIPS (1.6.0-notls (i386/linux)). > Content-Length: 0. > . > > On 1-Feb-10, at 8:55 AM, Bogdan-Andrei Iancu wrote: > > >> Hi Thamer, >> >> Could you post the first re-INVITE (received and sent) to see what >> could >> be the problem? >> >> Regards, >> Bogdan >> >> Thamer Alharbash wrote: >> >>> We currently have opensips setup to route through another carrier for >>> certain calls. All signaling and media works well except for >>> reinvites. >>> >>> if (has_totag()) { >>> >>> # sequential request within a dialog should >>> # take the path determined by record-routing >>> >>> if (loose_route()) { >>> if (is_method("BYE")) { >>> setflag(1); # do accounting ... >>> setflag(3); # ... even if the >>> transaction fails >>> } else if (is_method("INVITE")) { >>> # even if in most of the cases is >>> useless, do RR for >>> # re-INVITEs alos, as some buggy >>> clients do change route set >>> # during the dialog. >>> record_route_preset("<hidden>"); >>> } >>> fix_nated_contact(); >>> t_relay(); >>> ... >>> >>> The first reinvite passes through fine with the nated contact fixed >>> for the contact field. The second reinvite does not get relayed >>> correctly. Instead a udp packet with no SIP payload at all is sent to >>> the UA. We can't find any particular error in the debug log. >>> >>> Does anyone have thoughts on this? >>> >>> >>> >> -- >> Bogdan-Andrei Iancu >> www.voice-system.ro >> >> >> _______________________________________________ >> Users mailing list >> [email protected] >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > > -- Bogdan-Andrei Iancu www.voice-system.ro _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
