We've been using this provider for a few weeks now with no issues with termination to PSTN. Below is a sip trace from the PSTN to my interop system, with the hangup occuring from the PSTN. The sip trace appears to confirm that the BYE from the provider is formed correctly, and is properly relayed by openser.
Thanks Stagg Shelton
# U +3.305877 63.209.207.135:5060 -> 8.17.32.184:5060 BYE sip:6783832765@8.17.32.19 SIP/2.0* From: sip:8005555555@8.17.32.184;tag=88cfd13f-13c4-48b30a4f- e8021926-4d82d20d* To: "Stagg Test" sip:6783832765@8.17.32.19;tag=as20591d24* Call-ID: 0430a1061375ebc12c41bfb4170e854a@8.17.32.19* CSeq: 1 BYE* Via: SIP/2.0/UDP 63.209.207.135:5060;branch=z9hG4bK-9149-48b30a57-e8023819-4169a64b* Max-Forwards: 15* Route: sip:8.17.32.184;lr;did=f9.56eb2673* Content-Length: 0* *
# U +0.002395 8.17.32.184:5060 -> 8.17.32.19:5060 BYE sip:6783832765@8.17.32.19 SIP/2.0* From: sip:8005555555@8.17.32.184;tag=88cfd13f-13c4-48b30a4f- e8021926-4d82d20d* To: "Stagg Test" sip:6783832765@8.17.32.19;tag=as20591d24* Call-ID: 0430a1061375ebc12c41bfb4170e854a@8.17.32.19* CSeq: 1 BYE* Via: SIP/2.0/UDP 8.17.32.184;branch=z9hG4bK41a6.c4d351.0* Via: SIP/2.0/UDP 63.209.207.135:5060;branch=z9hG4bK-9149-48b30a57-e8023819-4169a64b* Max-Forwards: 14* Content-Length: 0* *
# U +0.003511 8.17.32.19:5060 -> 8.17.32.184:5060 SIP/2.0 200 OK* Via: SIP/2.0/UDP 8.17.32.184;branch=z9hG4bK41a6.c4d351.0;received=8.17.32.184* Via: SIP/2.0/UDP 63.209.207.135:5060;branch=z9hG4bK-9149-48b30a57-e8023819-4169a64b* From: sip:8005555555@8.17.32.184;tag=88cfd13f-13c4-48b30a4f- e8021926-4d82d20d* To: "Stagg Test" sip:6783832765@8.17.32.19;tag=as20591d24* Call-ID: 0430a1061375ebc12c41bfb4170e854a@8.17.32.19* CSeq: 1 BYE* User-Agent: Asterisk PBX* Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY* Supported: replaces* Contact: sip:6783832765@8.17.32.19* Content-Length: 0* *
On Aug 25, 2008, at 3:30 PM, Iñaki Baz Castillo wrote:
El Lunes, 25 de Agosto de 2008, Klaus Darilion escribió:
Hi!
For reference if you want to present some standards to your provider:
RFC 3261:
12.2.1.1 Generating the Request
...If the route set is not empty, and the first URI in the route set contains the lr parameter (see Section 19.1.1), the UAC MUST place the remote target URI into the Request-URI and MUST include a Route header field containing the route set values in order, including all parameters.
The remote target itself is defined in 12.1.2: ...The remote target MUST be set to the URI from the Contact header field of the response.
One question more: If you initiate an outgoing call through that provider, is it correctly established? In that case try to call to a PSTN phone of you, and hang up the call from the PSTN in order to receive a BYE from the provider. Is that BYE correctly generated? it should have a "Route: sip:openser_ip" and a RURI like the Contact you send in the INVITE.
-- Iñaki Baz Castillo
Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users