12 Oct
2005
12 Oct
'05
12:20 a.m.
For those of you who want to follow along, the packet dump in question
is at http://strike.dclg.ca/~dgilbert/22-3-filtered ... it's a pcap
format file.
I'm using a 0.9.4 copy of ser, compiled by hand on debian stable.
Only the core portion of ser is being used, and I have simple config
file (attached).
So, roughly, a call comes in level3, they make it SIP and forward it
to my SER on port 5070. SER turns around and forwarded it to asterisk
on port 5060 of the same machine and then asterisk forwards it on to a
linksys ATA.
In short, the problem is that level3 abuses the RFC by sending from a
port and expecting you to reply on another port (specified in the
Contact: header). This goes almost right except for level3's equally
literal read of the Contact header that SER sends.
Packet Sip Command Contact
====== =========== =======
level3:38999 ser:5070 INVITE sip:+1416...@<level3 ip>:5060
ser:5070 level3:38999 100 Trying sip:+1866...@<ser ip>
(ser invites asterisk, not in dump)
asterisk:5060 ata:5060 INVITE sip:+1416...@<asterisk ip>
ata:5060 asterisk:5060 100 Trying None
ata:5060 asterisk:5060 180 Ringing None
(asterisk relays 180 to ser, not in dump)
ser:5070 level3:38999 180 Ringing sip:+1866...@<ser ip>
ata:5060 asterisk:5060 200 OK sip:604...@<ata ip>:5060
asterisk:5060 ata:5060 ACK sip:+1416...@<asterisk ip>
(asterisk relays 200 OK to ser, not in dump)
ser:5070 level3:5060 200 OK sip:+1866...@<ser ip>
level3:5060 ser:5060 !?! ACK sip:+1866...@<level3 ip>:5060
Now... the problem is that each time ser repsonds, the contact line
should be appended with ":5070" and it is not. Therefore, being the
literal people they are, level3 repsonds to port 5060 with their ACK.
This means that the ACK goes directly to asterisk rather than to SER
and it means that when the call ends, the BYE notification from
asterisk goes directly to the wrong port at level3.
Dave.
--
============================================================================
|David Gilbert, Independent Contractor. | Two things can only be |
|Mail: dave(a)daveg.ca | equal if and only if they |
|http://daveg.ca | are precisely opposite. |
=========================================================GLO================
26 Oct
26 Oct
9:50 a.m.
Hello,
The packet dump and your description does not match. The messages in the
dump do not seem to go through SER at all, not even the INVITE. 200 OK
contains no Route header fields thus the gateway sends the ACK directly
to the other endpoint.
Jan.
On 11-10-2005 17:20, David Gilbert wrote:
Content-Description: message body text
For those of you who want to follow along, the packet
dump in question
is at http://strike.dclg.ca/~dgilbert/22-3-filtered ... it's a pcap
format file.
I'm using a 0.9.4 copy of ser, compiled by hand on debian stable.
Only the core portion of ser is being used, and I have simple config
file (attached).
So, roughly, a call comes in level3, they make it SIP and forward it
to my SER on port 5070. SER turns around and forwarded it to asterisk
on port 5060 of the same machine and then asterisk forwards it on to a
linksys ATA.
In short, the problem is that level3 abuses the RFC by sending from a
port and expecting you to reply on another port (specified in the
Contact: header). This goes almost right except for level3's equally
literal read of the Contact header that SER sends.
Packet Sip Command Contact
====== =========== =======
level3:38999 ser:5070 INVITE sip:+1416...@<level3 ip>:5060
ser:5070 level3:38999 100 Trying sip:+1866...@<ser ip>
(ser invites asterisk, not in dump)
asterisk:5060 ata:5060 INVITE sip:+1416...@<asterisk ip>
ata:5060 asterisk:5060 100 Trying None
ata:5060 asterisk:5060 180 Ringing None
(asterisk relays 180 to ser, not in dump)
ser:5070 level3:38999 180 Ringing sip:+1866...@<ser ip>
ata:5060 asterisk:5060 200 OK sip:604...@<ata ip>:5060
asterisk:5060 ata:5060 ACK sip:+1416...@<asterisk ip>
(asterisk relays 200 OK to ser, not in dump)
ser:5070 level3:5060 200 OK sip:+1866...@<ser ip>
level3:5060 ser:5060 !?! ACK sip:+1866...@<level3 ip>:5060
Now... the problem is that each time ser repsonds, the contact line
should be appended with ":5070" and it is not. Therefore, being the
literal people they are, level3 repsonds to port 5060 with their ACK.
This means that the ACK goes directly to asterisk rather than to SER
and it means that when the call ends, the BYE notification from
asterisk goes directly to the wrong port at level3.
Content-Description: message body and .signature
Dave.
--
============================================================================
|David Gilbert, Independent Contractor. | Two things can only be |
|Mail: dave(a)daveg.ca | equal if and only if they |
|http://daveg.ca | are precisely opposite. |
=========================================================GLO================
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
27 Oct
27 Oct
12:11 p.m.
David Gilbert wrote:
In short, the problem is that level3 abuses the RFC by
sending from a
port and expecting you to reply on another port (specified in the
Contact: header). This goes almost right except for level3's equally
literal read of the Contact header that SER sends.
Using different ports is valid. You have to differ between replys and
new transactions.
1. The replies (180, 200) must be sent to the port indicated in the Via
header. (except there is a rport parameter in the Via header from the
gateway). Thus, if the level3 gateway is "un-symmetrical" make sure to
no call force_rport for messages received from the level3 gateway.
2. Requests by the ATA sent to the gateway, must be sent to the IP:port
indicated in the Contact: header of the INVITE. Thus, make sure to not
call fix_nated_contact for requests received from the level3 gateway.
3. use ngrep -d any ... or tcpdump -i any ... to see also the packets on
the loopback device (between ser and asterisk)
regards
klaus
Packet Sip Command Contact
====== =========== =======
level3:38999 ser:5070 INVITE sip:+1416...@<level3 ip>:5060
ser:5070 level3:38999 100 Trying sip:+1866...@<ser ip>
(ser invites asterisk, not in dump)
asterisk:5060 ata:5060 INVITE sip:+1416...@<asterisk ip>
ata:5060 asterisk:5060 100 Trying None
ata:5060 asterisk:5060 180 Ringing None
(asterisk relays 180 to ser, not in dump)
ser:5070 level3:38999 180 Ringing sip:+1866...@<ser ip>
ata:5060 asterisk:5060 200 OK sip:604...@<ata ip>:5060
asterisk:5060 ata:5060 ACK sip:+1416...@<asterisk ip>
(asterisk relays 200 OK to ser, not in dump)
ser:5070 level3:5060 200 OK sip:+1866...@<ser ip>
level3:5060 ser:5060 !?! ACK sip:+1866...@<level3 ip>:5060
Now... the problem is that each time ser repsonds, the contact line
should be appended with ":5070" and it is not. Therefore, being the
literal people they are, level3 repsonds to port 5060 with their ACK.
This means that the ACK goes directly to asterisk rather than to SER
and it means that when the call ends, the BYE notification from
asterisk goes directly to the wrong port at level3.
------------------------------------------------------------------------
Dave.
------------------------------------------------------------------------
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
6966
days inactive
6982
days old
2 comments
3 participants
participants (3)
-
David Gilbert -
Jan Janak -
Klaus Darilion