Buenas tardes Tele
In the capture, I see the following call flow.
GW
WESIP
MS
------ INV(S1)---à
-------INV (S2) ------>
ß------183
-----------
------- 183 ----------->
ß--------ACK
---------
ß-------503
----------
...
14:07:57 19Mar2007 DEBUG SipProcessor
[SipProcessor[4]]- <<<<<<<<< Request Received
<<<<<<<<<
INVITE
sip:390104491079@82.215.163.67 SIP/2.0
Via: SIP/2.0/UDP
82.215.163.5:5060;branch=z9hG4bK6a4fa6b1
Max-Forwards: 69
From: <sip:3405300695@82.215.163.5>;tag=6a4fa6b1
To:
<sip:390104491079@82.215.163.67>
Call-ID: 1783604896-30787@SVIGateway
CSeq: 1 INVITE
Contact:
<sip:82.215.163.5:5060>
Content-Type:
application/sdp
Content-Length:
213
14:07:58 19Mar2007 DEBUG SipRequest [SipProcessor[4]]-
>>>>>>>>> Sending Request
>>>>>>>>>
INVITE
sip:199@82.215.133.50 SIP/2.0
Max-Forwards: 69
From:
<sip:3405300695@82.215.163.5>;tag=01E9CCA04D3CF9B8B3BE20CE1385BC2A
To:
<sip:390104491079@82.215.163.67>
CSeq: 1 INVITE
Content-Type:
application/sdp
Call-ID: 11111783604896-30787@SVIGateway
Contact:
<sip:82.215.163.67:5060;transport=udp>
Via: SIP/2.0/UDP
82.215.163.67:5060;branch=z9hG4bK477735439
Content-Length:
21314:07:58 19Mar2007 DEBUG SipProcessor [SipProcessor[4]]-
<<<<<<<<< Response Received
<<<<<<<<<
SIP/2.0 183
Session Progress
Via: SIP/2.0/UDP
82.215.163.67:5060;branch=z9hG4bK477735439
From:
<sip:3405300695@82.215.163.5>;tag=01E9CCA04D3CF9B8B3BE20CE1385BC2A
To:
<sip:390104491079@82.215.163.67>;tag=13FB8534-58
Date: Mon, 25 Mar
2002 04:04:50 GMT
Call-ID: 11111783604896-30787@SVIGateway
Server:
Cisco-SIPGateway/IOS-12.x
CSeq: 1 INVITE
Allow:
INVITE,CANCEL,ACK,BYE,INFO,OPTIONS,UPDATE,REGISTER,SUBSCRIBE,NOTIFY,PRACK,REFER
Allow-Events:
telephone-event
Contact:
<sip:199@82.215.133.50:5060>
Content-Type:
application/sdp
Content-Disposition:
oSystemsSIP-GW-UserAg
Content-Length: 235
14:07:58
19Mar2007 DEBUG SipResponse [SipProcessor[4]]-
>>>>>>>>> Sending Response
>>>>>>>>>
SIP/2.0 183
Session Progress
Via: SIP/2.0/UDP
82.215.163.5:5060;branch=z9hG4bK6a4fa6b1
Max-Forwards: 69
From:
<sip:3405300695@82.215.163.5>;tag=6a4fa6b1
To:
<sip:390104491079@82.215.163.67>
CSeq: 1 INVITE
Call-ID: 11111783604896-30787@SVIGateway
Content-Type:
application/sdp
Content-Length:
235
v=0
o=CiscoSystemsSIP-GW-UserAgent
9756
s=SIP Call
c=IN IP4
82.215.133.50
t=0 0
m=audio 19450
RTP/AVP 0 99
c=IN IP4
82.215.133.50
a=rtpmap:0
PCMU/8000
a=rtpmap:99
telephone-event/8000
a=fmtp:99 0-15
14:08:07 19Mar2007
DEBUG SipProcessor [SipProcessor[3]]-
<<<<<<<<< Request Received
<<<<<<<<<
ACK
sip:199@82.215.133.50 SIP/2.0
Via: SIP/2.0/UDP
82.215.163.67;branch=z9hG4bK07de.99a696f6.0
From:
<sip:3405300695@82.215.163.5>;tag=01E9CCA04D3CF9B8B3BE20CE1385BC2A
Call-ID: 11111783604896-30787@SVIGateway
To:
<sip:390104491079@82.215.163.67>;tag=13FB8534-58
CSeq: 1 ACK
User-Agent:
OpenSer (1.2.0-pre6-notls (i386/linux))
Content-Length: 0
14:08:07
19Mar2007 DEBUG SipProcessor [SipProcessor[4]]-
<<<<<<<<< Response Received
<<<<<<<<<
SIP/2.0 503
Service Unavailable
Via: SIP/2.0/UDP
82.215.163.67:5060;branch=z9hG4bK477735439
From:
<sip:3405300695@82.215.163.5>;tag=01E9CCA04D3CF9B8B3BE20CE1385BC2A
To:
<sip:390104491079@82.215.163.67>;tag=13FB8534-58
Date: Mon, 25 Mar
2002 04:04:50 GMT
Call-ID: 11111783604896-30787@SVIGateway
Server:
Cisco-SIPGateway/IOS-12.x
CSeq: 1 INVITE
Allow-Events:
telephone-event
Reason:
Q.850;cause=41
Content-Length: 0
The signalling is not correct but, I have looked your code
and believe that it is right, revise it and you check if you have the last
version of WeSIP and you return to try, because the last release commited in http://www.wesip.com/mediawiki/index.php/Downloads:WeSIP_Beta_0.1
was fixed a bug with the ApplicationSessions.
In my test application I reply your behaviour(with
5xx, with AppSession attributes) and all have working perfectly, I don’t
understand nothing :(
Sorry
Good Luck.
Antonio
-----Mensaje original-----
De: tele [mailto:tele@plexia.com]
Enviado el: martes, 20 de marzo de 2007 16:46
Para: users@openser.org
CC: antonio.abajo@voztele.com
Asunto: Re: RV: [Users] WeSIP session question
Hola Antonio,
Your example works great and the code is more clear
and correct than
mine :)
i was not clear, my problem was only with the 503
Service Unavailable
response, that means a 5xx Server Failure, is it
possibile that when the
container or openser with seas recive a 5xx response
is not able to do
for example a creation of a new invite to UA3 recover
from the same
session?. Or probably i'm occur in a 473 response for
an incorrect use
of SipApplicationSession.
anyway with a 480 Temporarily Unavailable response
from the UA2 i solve
my problem.
thank you very much
:tele
On Mon, 2007-03-19 at 19:27 +0100,
> Hola tele ;)
>
> I have tested an example similar to yours, and it
works ok. It's de
> following:
>
> UA1 ---[1]--> WeSIP --[2]--486 Busy
Here---> UA2
>
|
>
[3]
>
---OK----_> UA3
>
> [1] UA1 generates an INVITE to UA2 ant it 's
forwarded to UA2 with a B2BUA
> behaviour. In do INVITE. I have implemented the
following:
>
> protected void doInvite(SipServletRequest invite){
> SipServletRequest otherInvite
= sf.createRequest(invite, false);
> SipURI sipUri =
sf.createSipURI("UA2","proxy");
>
otherInvite.setRequestURI(sipUri);
>
otherInvite.getSession().setAttribute("REQUEST", otherInvite);
>
>
otherInvite.getSession().setAttribute("PEER_SESSION",invite.getSession());
>
>
invite.getSession().setAttribute("PEER_SESSION",otherInvite.getSession());
>
invite.getSession().setAttribute("REQUEST", invite);
> otherInvite.send();
> }
>
> [2] UA2 declines the call and a 486 response is
received by WeSIP and
> process it in doErrorResponse:
>
> protected void doErrorResponse(SipServletResponse
errorResponse) {
>
switch(errorResponse.getStatus()){
> case 486:
>
SipServletRequest request = (SipServletRequest)
>
errorResponse.getSession().getAttribute("REQUEST");
>
SipSession otherSession
= (SipSession)
>
errorResponse.getSession().getAttribute("PEER_SESSION");
>
SipURI sipUri = sf.createSipURI("UA3",
"proxy");
>
request.setRequestURI(sipUri);
>
SipServletRequest
newRequest =
> sf.createRequest(request,false);
>
newRequest.getSession().setAttribute("REQUEST", newRequest);
>
newRequest.getSession().setAttribute("PEER_SESSION",
> otherSession);
>
otherSession.setAttribute("PEER_SESSION",
> newRequest.getSession());
>
newRequest.setHeader("X-SSVTPBX", "yes");
>
newRequest.send();
>
break;
> }
> }
>
> [3] UA3 Recevies the second call and it takes
down.
>
>
> I do not understand the cause of error. I annex
you the code of simple sip
> application example that replies to your problem.
You can start it up and
> checking if it works. Else if work for you, I would
attempt watching the
> particular case when a 5XX responses are
received.
>
> Sorry...
>
> Best regards.
> Antonio.
>
> -----Mensaje original-----
> De: tele [mailto:tele@plexia.com]
> Enviado el: lunes, 19 de marzo de 2007 14:33
> Para:
> Asunto: RE: [Users] WeSIP session question
>
> Hola Antonio,
>
> The scenario is more complex, i'll try to explain
it:
>
> PSTN
> |
> |
> UA---->GW ------> WeSIP(B2BUA)
>
|
>
|
>
mediaserver
>
>
> GW: 82.215.163.5
> WeSIP: 82.215.163.67
> MS: 82.215.133.50
>
> in the mediaserver there is an vxml script that i
play in early media
> and in case of particular event return to wesip a
503 temporaly
> unavailable or e 410 Gone. So my B2BUA
application have control of this
> and can do stuff with the 503 and 410.
>
> in particular, in case of 503 temporaly
unavailable i get the upstream
> session and create a new invite to the media
server for play another
> announcement associated. in case of 410 gone i
generate a new invite to
> the GW with the original URI request for the
correct termination.
>
> Yes when the session is removed i'm able to send
another call.
>
> attached here the logs and the servlet.
>
> don't care about the hardcoded IP and the
repeated code :-)
> i'm doing testing..
>
> regards,
>
> :tele
>
>
> On Mon, 2007-03-19 at 13:29 +0100,
> > Hi Tele,
> >
> > I don't understand very well the problem.,
for what I understand you have
> > the following:
> >
> >
> > UA1 --------------------- WeSIP
--------------------- UA2
> >
> > ---INV/4XX-6XX/ACK (SS1) -->
----INV/4XX-6XX/ACK(SS2)-->
> >
> > You try to send another call and receive the
473 response of WeSIP...
> >
> > ------INV/473/ACK (SS1) -->
> >
> > And when the session has been removed you
can send another call.
> >
> > If it is the case, I understand that the 473
response is send from
> > application or from openser script configuration,
because the internal
> > behaviour of SIP doesn't send this response
automatically.
> >
> > Can you verify if it is the case?
> >
> > Thank you very much...
> >
> > Antonio.
> >
> > -----Mensaje original-----
> > De: users-bounces@openser.org
[mailto:users-bounces@openser.org] En nombre
> > de tele
> > Enviado el: lunes, 19 de marzo de 2007 12:35
> > Para: users@openser.org
> > Asunto: [Users] WeSIP session question
> >
> > Hi,
> >
> > I've a problem with WeSIP in B2BUA mode, in case
of failed call 4xx-6xx
> > correctly terminated, when i try to send
another call to WeSIP i recive
> > a "473 Filtered destination" then
for send another call i've to wait
> > WeSIP complete some management with session:
> >
> > 14:10:16 19Mar2007 DEBUG SipConnector
[SipProcessor[3]]- recycle:
> > Recycling processor SipProcessor[3]
> > 14:10:56 19Mar2007 DEBUG
StandardAppSessionManager
> > [StandardAppSessionManager[/inapp]]-
AppSession Id
> > [B4D6C9C4288784A68E032D20AB78BD8E] with a
number of sessions =1
> > 14:10:56 19Mar2007 DEBUG
StandardAppSessionManager
> >
[StandardAppSessionManager[/inapp]]-
SipSession
> > [z9hG4bK69e6006f] in state [3] with lifetime
of :74490
> > 14:10:56 19Mar2007 DEBUG
StandardAppSessionManager
> > [StandardAppSessionManager[/inapp]]-
AppSession Id
> > [E3E1D9414BC47572CBC73EC7B4A53531] with a
number of sessions =1
> > 14:10:56 19Mar2007 DEBUG
StandardAppSessionManager
> >
[StandardAppSessionManager[/inapp]]-
SipSession
> > [z9hG4bK69e68616] in state [3] with lifetime
of :40281
> > 14:11:56 19Mar2007 DEBUG
StandardAppSessionManager
> > [StandardAppSessionManager[/inapp]]-
AppSession Id
> > [B4D6C9C4288784A68E032D20AB78BD8E] with a
number of sessions =1
> > 14:11:56 19Mar2007 DEBUG
StandardAppSessionManager
> >
[StandardAppSessionManager[/inapp]]-
SipSession
> > [z9hG4bK69e6006f] in state [3] with lifetime
of :134500
> > 14:11:56 19Mar2007 DEBUG
StandardAppSessionManager
> > [StandardAppSessionManager[/inapp]]-
AppSession Id
> > [E3E1D9414BC47572CBC73EC7B4A53531] with a
number of sessions =1
> > 14:11:56 19Mar2007 DEBUG
StandardAppSessionManager
> >
[StandardAppSessionManager[/inapp]]-
SipSession
> > [z9hG4bK69e68616] in state [3] with lifetime
of :100291
> > 14:12:56 19Mar2007 DEBUG
StandardAppSessionManager
> > [StandardAppSessionManager[/inapp]]-
AppSession Id
> > [B4D6C9C4288784A68E032D20AB78BD8E] with a
number of sessions =0
> > 14:12:56 19Mar2007 DEBUG
StandardAppSessionManager
> > [StandardAppSessionManager[/inapp]]- Remove
AppSession
> > [B4D6C9C4288784A68E032D20AB78BD8E]
> >
> > When i see Remove AppSession i'm able to
send another call...
> > I've read the sip servlet spec about that
and i'm trying to invalidate()
> > or setExpires() to SiApplicationSession in case
of failed call. but it's
> > not clear how to do yet.
> >
> > i can provide the full debug if needed.
> >
> > thank you!
> >
> > regards
> >
> > :tele
> >
> >
> >
> >
_______________________________________________
> > Users mailing list
> > Users@openser.org
> >
http://openser.org/cgi-bin/mailman/listinfo/users
>
> _______________________________________________
> Users mailing list
> Users@openser.org
> http://openser.org/cgi-bin/mailman/listinfo/users
--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.446 / Virus Database: 268.18.14/727 -
Release Date: 19/03/2007 11:49
--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.446 / Virus Database: 268.18.14/727 -
Release Date: 19/03/2007 11:49