Hi Jon,

Which Cisco gw are you using?  We have a Cisco AS5350 running 12.3(8)T3.  I attempted to reproduce what you saw but did not see the same symptom.  Which softphone?

Dan


On 7/20/05, Jon Mansey <jon@tigrisnet.net> wrote:
In the following scenario, it seems that ser may not be sending the BYE to
the right port on the cisco, is that possible? The cisco is not registered
with ser, it is a trusted IP. The DID is an alias for my softphone UID. This
only happens for pstn-voip calls, when calling voip-pstn, ser always talks
to the cisco on port 5060 and the BYE is obeyed, whichever end sends it
first.


call scenario

dial DID from pstn phone

cisco:51339 -> ser:5060         INVITE
ser:5060        -> cisco:51339  100 trying
ser:5060        -> cisco:51339  180 ringing     softphone ringing
ser:5060        -> cisco:51339  200 OK  softphone answered
cisco:53924     -> ser:5060     ACK

call in progress, 2 way audio

I hang up the softphone

ser:5060        -> cisco:51339  BYE     softphone says "hanging up"
ser:5060        -> cisco:51339  BYE
ser:5060        -> cisco:51339  BYE
ser:5060        -> cisco:51339  BYE
ser:5060        -> cisco:51339  BYE
ser:5060        -> cisco:51339  BYE
ser:5060        -> cisco:51339  BYE


ser:5060        -> softphone:5060 TIMEOUT  softphone says "hung up"

pstn phone still off hook, call up still

i hang up the pstn phone

cisco:50580     -> ser:5060     BYE
ser:5060        -> cisco:5060   OK
ser:5060        -> cisco:51339  BYE

So the cisco has used 3 different ports during this call, one for the
INVITE, which ser then uses to send replies back to, but the ACK comes from
a new port, and then the eventual BYE comes from a 3rd port.

I can understand how the cisco tries not to be stateful and uses different
ports for each message, but how is ser supposed to communicate back to it if
not on the port used by the original INVITE? Perhaps it should only talk to
the cisco on port 5060? If so how do I make it do that? Is the cisco
misbehaving by using many different ports when it originates the sip call?
Is that a known IOS bug perhaps?

Help and wisdom appreciated,

Jon


_______________________________________________
Serusers mailing list
Serusers@iptel.org
http://mail.iptel.org/mailman/listinfo/serusers