16 May
2006
16 May
'06
10:55 p.m.
Greetings,
I'm new to this list so I don't know whether this should be here or on
the developer's list.
I've been running a test and come across a problem. I have three phones
and the SER proxy. Two of the phones are softphones, the third is an
ATA. The ATA is at 192.168.1.3, and the two softphones are at
192.168.1.4 and 192.168.1.5. SER is at 192.168.1.7.
In the test, 192.168.1.3 and 192.168.1.4 register with the SER as AOR
'100'. 192.168.1.5 then make a call to sip:100@192.168.1.7. The INVITE
is forked properly however there is some strange behavior with the ACK
handling. It appears that no matter which of the phones answers, the
ACK is always sent to the first phone to have registered for the AOR,
whether that was the phone that answers or not.
I have included an Ethereal trace file that illustrates this behavior.
If you graph the VoIP call you can clearly see this situation occuring.
You should be able to load this file directly into Ethereal.
I would be interested in anyones thoughts on whether this is a bug or
not in SER or something else.
Thanks,
FM
16 May
16 May
11:08 p.m.
Frank,
If you are calling from 192.168.1.5 why do both the To and From fields in
the initial INVITE show sip:100@192.168.1.7?
Leo P.
-----Original Message-----
From: serusers-bounces(a)iptel.org [mailto:serusers-bounces@lists.iptel.org] On
Behalf Of Frank W. Miller
Sent: Tuesday, May 16, 2006 10:56 PM
To: serusers(a)lists.iptel.org
Subject: [Serusers] Forking problem
Greetings,
I'm new to this list so I don't know whether this should be here or on
the developer's list.
I've been running a test and come across a problem. I have three phones
and the SER proxy. Two of the phones are softphones, the third is an
ATA. The ATA is at 192.168.1.3, and the two softphones are at
192.168.1.4 and 192.168.1.5. SER is at 192.168.1.7.
In the test, 192.168.1.3 and 192.168.1.4 register with the SER as AOR
'100'. 192.168.1.5 then make a call to sip:100@192.168.1.7. The INVITE
is forked properly however there is some strange behavior with the ACK
handling. It appears that no matter which of the phones answers, the
ACK is always sent to the first phone to have registered for the AOR,
whether that was the phone that answers or not.
I have included an Ethereal trace file that illustrates this behavior.
If you graph the VoIP call you can clearly see this situation occuring.
You should be able to load this file directly into Ethereal.
I would be interested in anyones thoughts on whether this is a bug or
not in SER or something else.
Thanks,
FM
11:15 p.m.
Because the call is supposed to be coming from the AOR associated with
the Service Provider that SER is representing? From 3261:
8.1.1.3 From
The From header field indicates the logical identity of the initiator
of the request, possibly the user's address-of-record.
The Contact header has the actual UA address in it.
Thanks,
FM
On Tue, 2006-05-16 at 23:08 -0400, Leo wrote:
Frank,
If you are calling from 192.168.1.5 why do both the To and From fields in
the initial INVITE show sip:100@192.168.1.7?
Leo P.
-----Original Message-----
From: serusers-bounces(a)iptel.org [mailto:serusers-bounces@lists.iptel.org] On
Behalf Of Frank W. Miller
Sent: Tuesday, May 16, 2006 10:56 PM
To: serusers(a)lists.iptel.org
Subject: [Serusers] Forking problem
Greetings,
I'm new to this list so I don't know whether this should be here or on
the developer's list.
I've been running a test and come across a problem. I have three phones
and the SER proxy. Two of the phones are softphones, the third is an
ATA. The ATA is at 192.168.1.3, and the two softphones are at
192.168.1.4 and 192.168.1.5. SER is at 192.168.1.7.
In the test, 192.168.1.3 and 192.168.1.4 register with the SER as AOR
'100'. 192.168.1.5 then make a call to sip:100@192.168.1.7. The INVITE
is forked properly however there is some strange behavior with the ACK
handling. It appears that no matter which of the phones answers, the
ACK is always sent to the first phone to have registered for the AOR,
whether that was the phone that answers or not.
I have included an Ethereal trace file that illustrates this behavior.
If you graph the VoIP call you can clearly see this situation occuring.
You should be able to load this file directly into Ethereal.
I would be interested in anyones thoughts on whether this is a bug or
not in SER or something else.
Thanks,
FM
6665
days inactive
6665
days old
2 comments
2 participants
participants (2)
-
Frank W. Miller -
Leo