| < Previous by Date | Date Index | Next by Date > |
| < Previous in Thread | Thread Index |
If approval is granted, the UA MUST contact the resource identified by the URI in the Refer-To header field value as discussed in Section 2.4.3.
Since a URI parameter is part of the URI, then it should end up in the To header of the resulting INVITE. This is not explicitly spelled out in the RFC, but I would have thought you would have a pretty good success rate with this approach. If you passed such a Refer-To header to resiprocate it would preserve the URI parameters (except for the 'method' parameter), in the resulting INVITE.
ScottScott,The below suggestion didn't wok with Asterisk SBC.I am not getting usertouser information in INVITE's To field, though I am getting INVITE at the correct UA.BTW, To which RFC the below suggestion belong to?Is there any other way to pass Application data from REFER to corresponding INVITE?Thanks,~ RajeevSent: Wednesday, April 15, 2009 6:19 AM
To: Srivastava, Rajeev Kumar (Rajeev)
Cc: resiprocate-users@xxxxxxxxxxxxxxx
Subject: Re: [reSIProcate-users] Query on UA iMPLEMENTATIONTake a look at the following wiki page for instructions on using Extension Parameters: http://www.resiprocate.org/Use_Overview#Extension_parametersThe general idea is:static const resip::ExtensionParameter p_usertouser("usertouser");msg.header(h_ReferTo).uri().param(p_usertouser) = "blah";On the receiving end you can look for existance by:if(msg.header(h_To).uri().exists(p_usertouser)){Data usertouserData = msg.header(h_To).uri().param(p_usertouser);}You should actually be able to just add this custom parameter to the URI you pass to the InviteSesion::refer() API, and you won't need to use the message decorator to do this.
ScottOn Tue, Apr 14, 2009 at 3:30 AM, Srivastava, Rajeev Kumar (Rajeev) <srivastava@xxxxxxxxx> wrote:
Hello Scott,I am using following piece of code to embed User-to-User into Refer-To field of the REFER message.<snip>class CAddCallInfo : public DumFeatureSharedPtr< DumFeature > featDUM( new CAddCallInfo ( this, *m_pDUM, m_pDUM->dumOutgoingTarget () ) );
m_pDUM->addOutgoingFeature ( featDUM );resip::DumFeature::ProcessingResult CAddCallInfo::process ( Message *pSipMsg )
{
OutgoingEvent *ogEv = dynamic_cast< OutgoingEvent* > ( pSipMsg );
if ( ogEv )
{
SharedPtr< SipMessage >& sipMsg = ogEv->message ();if ( sipMsg ){
if ( sipMsg->isRequest () )
{
switch ( sipMsg->header ( h_CSeq ).method () )
{
case REFER:
{
Data dDecor = Data ( m_strUniqueCallIdentifier.data () );
Uri uFrom = sipMsg->header ( h_ReferTo ).uri ();
Data dTest = Data::from ( uFrom );
resip::Data::size_type iFound = dTest.find ( "User-to-User" );
if ( iFound > 0 && iFound < dTest.size () )
{
DebugLog ( << "Skipping User-to-User decoration with REFER: " << dDecor );
}
else
{
DebugLog ( << "Adding User-to-User decoration with REFER: " << dDecor );
uFrom.embedded ().addHeader ( resip::Headers::UNKNOWN,
"User-to-User",
strlen ( "User-to-User" ),
dDecor.c_str (),
dDecor.size () );
sipMsg->header ( h_ReferTo ).uri () = uFrom;
}
}
break;
default:
break;
}
}
}
}
return DumFeature::FeatureDone;
}</snip>Could you please help me on how to use custome URI here in place of embedded header through a sample code?Thanks,~ Rajeev
Sent: Monday, April 13, 2009 11:18 PM
To: Srivastava, Rajeev Kumar (Rajeev)
Cc: resiprocate-users@xxxxxxxxxxxxxxx
Subject: Re: [reSIProcate-users] Query on UA iMPLEMENTATIONYou are using a custom embedded SIP header in your refer To header, I'm suggesting that you use a custom URI parameter instead. ie:Refer-To: "Avaya IC 7.2 B2B"<sip:62011@xxxxxxxxx;usertouser=00AA1049e2ddf1000000009493da8623320002BB102d37323030354061766179612e636f6d>Most endpoints should end up sending an INVITE with the following as the To header:INVITE ........
To: "62001"<sip:62001@xxxxxxxxx;usertouser=00AA1049e2ddf1000000009493da8623320002BB102d37323030354061766179612e636f6d>You application can then parse the To URI parameter out to get the unique call id.Scott
On Mon, Apr 13, 2009 at 3:11 AM, Srivastava, Rajeev Kumar (Rajeev) <srivastava@xxxxxxxxx> wrote:
Hello Scott,Following is the sequence of SIP message for a call coming on to Route Point UA (62001) and Referred to B2B UA (62011) for a call coming from Customer (72006)1. Customer calls & SBC sends INVITE to Route PointINVITE sip:62001@xxxxxxxxxxxxxxx:5129 SIP/2.0
Via: SIP/2.0/UDP 148.147.174.64:5060;branch=z9hG4bK030303434343030303448d.0
Via: SIP/2.0/TLS 148.147.174.131;psrrposn=2;received=148.147.174.131;branch=z9hG4bK0405559be31de14cd549f6573e00
Max-Forwards: 69
Record-Route: <sip:148.147.174.64:5060;lr>
Record-Route: <sip:148.147.174.131:5061;lr;transport=tls>
Contact: "RajeevSIP2"<sip:72006@xxxxxxxxxxxxxxx:5061;transport=tls>
To: "62001"<sip:62001@xxxxxxxxx>
From: "RajeevSIP2"<sip:72006@xxxxxxxxx:5061>;tag=0405559be31de14ad549f6573e00
Call-ID: 0405559be31de14bd549f6573e00
CSeq: 1 INVITE
Session-Expires: 1200;refresher=uac
Min-SE: 1200
Allow: INVITE, CANCEL, BYE, ACK, PRACK, SUBSCRIBE, NOTIFY, REFER, OPTIONS
Content-Type: application/sdp
Supported: 100rel, timer, replaces, join, histinfo
User-Agent: Avaya CM/R014x.00.0.730.5
P-Asserted-Identity: "RajeevSIP2" <sip:72006@xxxxxxxxx:5061>
Content-Length: 210
History-Info: <sip:62001@xxxxxxxxx>;index=1,"62001" <sip:62001@xxxxxxxxx>;index=1.1
v=0
o=- 1 1 IN IP4 148.147.174.131
s=-
c=IN IP4 148.147.174.132
t=0 0
m=audio 2980 RTP/AVP 0 18 4 127
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=rtpmap:4 G723/8000
a=rtpmap:127 telephone-event/8000
2. Route Point Sends 183 to SBCSIP/2.0 183 Session Progress
Via: SIP/2.0/UDP 148.147.174.64:5060;branch=z9hG4bK030303434343030303448d.0
Via: SIP/2.0/TLS 148.147.174.131;psrrposn=2;received=148.147.174.131;branch=z9hG4bK0405559be31de14cd549f6573e00
Record-Route: <sip:148.147.174.64:5060;lr>
Record-Route: <sip:148.147.174.131:5061;lr;transport=tls>
Contact: <sip:62001@xxxxxxxxxxxxxxx:5129>
To: "62001"<sip:62001@xxxxxxxxx>;tag=15152900
From: "RajeevSIP2"<sip:72006@xxxxxxxxx:5061>;tag=0405559be31de14ad549f6573e00
Call-ID: 0405559be31de14bd549f6573e00
CSeq: 1 INVITE
User-Agent: AvSIP 7.2.0-62001
Content-Length: 03. Route Point sends REFER to Customer with Unique Call Identifier attached to Refer-To fieldREFER sip:72006@xxxxxxxxxxxxxxx:5061;transport=tls SIP/2.0
Via: SIP/2.0/ ;branch=z9hG4bK-d8754z-9d09775c8f153173-1---d8754z-;rport
Max-Forwards: 70
Route: <sip:148.147.174.64:5060;lr>
Route: <sip:148.147.174.131:5061;lr;transport=tls>
Contact: <sip:62001@xxxxxxxxxxxxxxx:5129>
To: "RajeevSIP2"<sip:72006@xxxxxxxxx:5061>;tag=0405559be31de14ad549f6573e00
From: "62001"<sip:62001@xxxxxxxxx>;tag=15152900
Call-ID: 0405559be31de14bd549f6573e00
CSeq: 3 REFER
Proxy-Authorization: Digest username="62001",realm="avaya.com",nonce="MTIzOTU5Njg3MTpTREZTZXJ2ZXJTZWNyZXRLZXk6MTAwMzk3NDI2NA==",uri="sip:72006@xxxxxxxxxxxxxxx:5061;transport=tls",response="cc81f55789884ea2776eb30ed7a4d9cb",algorithm=MD5
User-Agent: AvSIP 7.2.0-62001
Refer-To: "Avaya IC 7.2 B2B"<sip:62011@xxxxxxxxx?User-to-User=00AA1049e2ddf1000000009493da8623320002BB102d37323030354061766179612e636f6d>
Referred-By: "62001"<sip:62001@xxxxxxxxx>
Content-Length: 04. SBC sends INVITE to B2B UA after parsing Refer-To field of the REFER messageINVITE sip:62011@xxxxxxxxxxxxxxx:5060 SIP/2.0
Via: SIP/2.0/UDP 148.147.174.64:5060;branch=z9hG4bK838383030303434343e5f2.0
Via: SIP/2.0/TLS 148.147.174.131;psrrposn=2;received=148.147.174.131;branch=z9hG4bK80405559be31de150d549f6573e00
Max-Forwards: 68
Record-Route: <sip:148.147.174.64:5060;lr>
Record-Route: <sip:148.147.174.131:5061;lr;transport=tls>
Contact: "62001"<sip:62001@xxxxxxxxxxxxxxx:5061;transport=tls>
To: "62011"<sip:62011@xxxxxxxxx>
From: "RajeevSIP2"<sip:72006@xxxxxxxxx:5061>;tag=80405559be31de14ed549f6573e00
Call-ID: 80405559be31de14fd549f6573e00
CSeq: 1 INVITE
Session-Expires: 1200;refresher=uac
Min-SE: 1200
Allow: INVITE, CANCEL, BYE, ACK, PRACK, SUBSCRIBE, NOTIFY, REFER, OPTIONS
Content-Type: application/sdp
Supported: 100rel, timer, replaces, join, histinfo
User-Agent: Avaya CM/R014x.00.0.730.5
Referred-By: "62001" <sip:62001@xxxxxxxxx>
P-Asserted-Identity: "62001" <sip:62001@xxxxxxxxx:5061>
Content-Length: 210
User-to-User: 00AA1049e2ddf1000000009493da8623320002BB102d37323030354061766179612e636f6d
History-Info: <sip:62011@xxxxxxxxx>;index=1,"62011" <sip:62011@xxxxxxxxx>;index=1.1v=0
o=- 1 1 IN IP4 148.147.174.131
s=-
c=IN IP4 148.147.174.132
t=0 0
m=audio 2988 RTP/AVP 0 18 4 127
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=rtpmap:4 G723/8000
a=rtpmap:127 telephone-event/8000Here my application sends REFER with unique call identifier attached to Refer-To field as User-to-User information.SBC parses that information and sends it back along with the INVITE as User-to-User filed.I've tested this with other SBCs (Asterisk, Ingate) and they also do not send the information encoded with Refer-To field in INVITE's To field. Thats why I modified my current SBC to do this trick for me. And due to this my application can run only with my modified SBC.I am not clear if you are suggesting something different.Or do I need to do it in some other manner?Thanks,~ Rajeev
From: slgodin@xxxxxxxxx [mailto:slgodin@xxxxxxxxx] On Behalf Of Scott Godin
Sent: Sunday, April 12, 2009 11:14 PM
To: Srivastava, Rajeev Kumar (Rajeev)
Cc: resiprocate-users@xxxxxxxxxxxxxxx
Subject: Re: [reSIProcate-users] Query on UA iMPLEMENTATIONWhy don't you encode the unique call identifier in the Refer to URI, as a custom URI parameter. This parameter should end up in the To header of the resulting INVITE request from the endpoint receiving the REFER? The B2BUA can then extract the unique identifier from the To header. This should work for any SBC vendor in your setup.Scott
On Sun, Apr 12, 2009 at 12:55 PM, Srivastava, Rajeev Kumar (Rajeev) <srivastava@xxxxxxxxx> wrote:
Hi,I am using resiprocate for one of my contact center project and I've a small query.In my application there are 2 types of UAs :-1. Route Point UA - Customers make call to these UAs which can be multiple2. B2B UA - This is a single call controller. It controls the signaling of call between Customer & contact center Agents.The current design is that Customer calls Route Point UA and then my application generates a unique identifier and asks customer to REFER the call to B2B UA along with the unique call identifier. In result a new INVITE is received by B2B UA along with unique call identifier in a custom header. To achieve this we have modified the SBC code to accept REFER with call identifier, parse it and send it back with INVITE. This is not is accordance with standard SIP Protocol. An in this way we can only support those SBCs who are capable of doing the above trick.Is there any way in resiprocate to give the SIP call arrived on Route Point UA to B2B internally without any REFER or REDIRECT.Any other idea on how to achieve this without changing our application architecture.For the application this unique call identifier is a must to proceed ahead.I wanted to support all SBCs with my current application architecture which I am not able to achieve because of application's dependency on call identifier within the current architecture.Please let me know if I am not clear with my query.Thanks,~ Rajeev
_______________________________________________
resiprocate-users mailing list
resiprocate-users@xxxxxxxxxxxxxxx
List Archive: http://list.resiprocate.org/archive/resiprocate-users/