[Serusers] Cisco pstn gw ignoring BYE from ser

Greger V. Teigre greger at teigre.com
Thu Jul 21 07:28:29 CEST 2005


MessageMy experience is that you can answer to both 5060 and the source port with the same result as long as the message is part of a previous dialog.  Cisco normally announces 5060 in Contact.  I have never seen the refused BYE either.  BYE is the start of a new dialog and I'm not sure how you make ser send to the high source port in your ser.cfg. I would try using rewritehostport("cisco_ip:5060") for all messages to the gw.
g-)

---- Original Message ----
From: Jon Mansey
To: 'Daniel Poulsen'
Cc: serusers at lists.iptel.org
Sent: Thursday, July 21, 2005 12:58 AM
Subject: RE: [Serusers] Cisco pstn gw ignoring BYE from ser

> Gateway is a 3600 running 12.something, softphone is X-ten, but the
> softphone is irrelevant, it happens on all UAs. 
> 
> User-Agent: Cisco-SIPGateway/IOS-12.x
> 
> what port do the original invite and subsequent messages come from if
> you originate a pstn call to ser from your cisco, if you dont me me
> asking?  
> 
> 
> 
> 
> -----Original Message-----
> From: Daniel Poulsen [mailto:dpoulsen at gmail.com]
> Sent: Wednesday, July 20, 2005 3:01 PM
> To: Jon Mansey
> Cc: serusers at lists.iptel.org
> Subject: Re: [Serusers] Cisco pstn gw ignoring BYE from ser
> 
> 
> 
> 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 at 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 at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Serusers mailing list
> serusers at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20050721/42cd193f/attachment.htm>


More information about the sr-users mailing list