< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index  

Re: [reSIProcate-users] Sening a SIP MESSAGE (in the context of a dialog)


Byron,

I did some customization of Resiprocate since my application (M1)  has to send 
SIP MESSAGE on behalf of another machine (M2) in the network (basically M1 
imitates M2 only for SIP MESSAGEs). 

M1 gets "From, to, FromTag and ToTag" from M2 and has to send a SIP Messages 
out. I did that by adding BaseCreator::makeMyOwninititalRequest(), which gets 
called instead of  BaseCreator::makeInitialRequest() for SIP MESSAGES. I also 
added  my own version of makeClientPagerMessage(). 

It gets little tricky here because M1 and M2 both can accept SIP INVITES. So 
for a SIP session established in M2, M1 sends out SIP MESSAGE using params. 
received from M2, by calling my customized functions. Everything looks okay. 
For SIP sessions established in M1 itself, I don't send SIP MESSAGES as 
in-dialog. I use my customized function (my version of 
makeClientPagerMessage()) and send SIP messages as out-of-dialog. It gets 
complicated here. SIP responses are received in-dialog for the SIP messages I 
sent as out-of-dialog (for SIP sessions established in M1). That is fine with 
me too.

But when the remote end sends a BYE (for SIP sessions established in M1), 
Resiprocate sends 481. I'm not able to understand why. I think it is something 
to do with a invite session and client pager message existing with the same 
callid, from, to, fromtag and totag. (is it ???)

Here is the debug log from Resiprocate:
DEBUG | 20090430-193705.519 | VAPPS | RESIP:DUM | 3075263392 | 
DialogUsageManager.cxx:1675 | DialogUsageManager::processRequest: SipReq:  BYE 
7771212_200004981_Moderator@xxxxxxxxxxxxx:5060 tid=7e7f.1c9aa7c7.0 cseq=BYE 
contact=199@xxxxxxxxxxxxx:7151 / 4 from(wire)
INFO | 20090430-193705.519 | VAPPS | RESIP:DUM | 3075263392 | 
DialogUsageManager.cxx:1735 | Handling in-dialog request: SipReq:  BYE 
7771212_200004981_Moderator@xxxxxxxxxxxxx:5060 tid=7e7f.1c9aa7c7.0 cseq=BYE 
contact=199@xxxxxxxxxxxxx:7151 / 4 from(wire)
DEBUG | 20090430-193705.519 | VAPPS | RESIP:DUM | 3075263392 | DialogId.cxx:50 
| DialogId::DialogId: 
N2MzMWViMDI0MzE1ODY0YmJhNzVkMTBlMDVlYWNlNjI.-63435928-dcc02323
DEBUG | 20090430-193705.519 | VAPPS | RESIP | 3075263392 | Helper.cxx:375 | 
Helper::makeResponse(SipReq:  BYE 
7771212_200004981_Moderator@xxxxxxxxxxxxx:5060 tid=7e7f.1c9aa7c7.0 cseq=BYE 
contact=199@xxxxxxxxxxxxx:7151 / 4 from(wire) code=481 reason=
DEBUG | 20090430-193705.519 | VAPPS | RESIP:DUM | 3075263392 | 
DialogUsageManager.cxx:890 | SEND: ^M
^M
SIP/2.0 481 Call/Transaction Does Not Exist^M
Via: SIP/2.0/UDP 192.168.1.160;branch=z9hG4bK7e7f.1c9aa7c7.0^M
Via: SIP/2.0/UDP 
192.168.1.178:7151;branch=z9hG4bK-d8754z-ff6f1f6030ceb77e-1---d8754z-;rport=7151^M
To: <sip:7771212_200004981_Moderator@xxxxxxxxxxxxx:5060>;tag=63435928^M
From: <sip:199@xxxxxxxxxxxxx>;tag=dcc02323^M
Call-ID: N2MzMWViMDI0MzE1ODY0YmJhNzVkMTBlMDVlYWNlNjI.^M
CSeq: 4 BYE^M
User-Agent: Vapps ^M
Content-Length: 0^M

Vasanthi



-----Original Message-----
From: Byron Campen [mailto:bcampen@xxxxxxxxxxxx] 
Sent: Thursday, April 30, 2009 12:13 PM
To: Vasanthi Ramasamy
Cc: resiprocate-users@xxxxxxxxxxxxxxx
Subject: Re: [reSIProcate-users] Sening a SIP MESSAGE (in the context of a 
dialog)

        They'll be routed back to your ClientPagerMessage, if that is what  
you mean, but they won't end up back at your InviteSession.

Best regards,
Byron Campen

> Thanks Byron for the response.
>
> I thought of a work around:
> Send all SIP MESSAGEs from Server as an out-of-dialog one even  
> though these is an existing dialog, by creating a  
> ClientPagerMessage() in my application. And the responses I will be  
> processing them as in-dialog, because of this code in resip/dum/ 
> DialogSet.cxx:
>
>        case MESSAGE:
>             if (dialog)
>            {
>                break;
>            }
>            else if (mClientPagerMessage)
>            {
>               mClientPagerMessage->dispatch(response);
>            }
>            return;
>
> hope this will solve my problem....
>
> -Vasanthi
>
>
>
> -----Original Message-----
> From: Byron Campen [mailto:bcampen@xxxxxxxxxxxx]
> Sent: Thursday, April 30, 2009 10:49 AM
> To: Vasanthi Ramasamy
> Cc: resiprocate-users@xxxxxxxxxxxxxxx
> Subject: Re: [reSIProcate-users] Sening a SIP MESSAGE (in the  
> context of a dialog)
>
> Well, you could configure SER to not Record-Route. And, I am betting  
> there is a way to put SER into a dialog-stateless mode, which would  
> also work. I'd go ask the SER folks whether there is some bit of  
> configuration to tweak to get correct behavior. If you absolutely  
> need to hack things together (and are willing to break spec in a  
> pretty egregious way), you could use an outbound decorator to strip  
> the Record-Route headers from the outgoing MESSAGE. (see  
> Profile::setOutboundDecorator()) But, this really should be your  
> last resort, and it should not be viewed as a long-term solution (or  
> really a solution at all).
>
>
> Best regards,
> Byron Campen
>
>
>
> Hi,
>
> I have a situation. Here is the scenario...
>
> 1. Remote client establishes a dialog with the server, which is  
> running Resiprocate 1.4 through a proxy (Openser). So INVITE, 180,  
> 200, Ack flow through the proxy.
> 2. Server has to send a SIP MESSAGE to the remote end in the context  
> of a dialog (by calling message() in InviteSession.cxx). And that  
> gets sent to the proxy, which throws it away with a 481 response.
>
> Now is there a way I can tell Resiprocate server to send SIP  
> MESSAGEs (only) directly to the remote end, instead of proxy.  
> (Request Line in the SIP MESSAGE points to the remote client).
>
> Thanks,
> Vasanthi
>
> _______________________________________________
> resiprocate-users mailing list
> resiprocate-users@xxxxxxxxxxxxxxx
> List Archive: http://list.resiprocate.org/archive/resiprocate-users/
>
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.0.238 / Virus Database: 270.12.2/2074 - Release Date:  
> 04/30/09 06:01:00


No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 8.0.238 / Virus Database: 270.12.2/2074 - Release Date: 04/30/09 
17:53:00