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.
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@daveg.ca | equal if and only if they | |http://daveg.ca | are precisely opposite. | =========================================================GLO================
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-
David Gilbert -
Jan Janak -
Klaus Darilion