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(a)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(a)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(a)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(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users