Re: [reSIProcate-users] Query on UA iMPLEMENTATION
- From: "Srivastava, Rajeev Kumar (Rajeev)" <srivastava@xxxxxxxxx>
- Date: Tue, 14 Apr 2009 13:00:40 +0530
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
DumFeature
SharedPtr< 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
You are using a custom embedded SIP header in your refer To header,
I'm suggesting that you use a custom URI parameter instead. ie:
Most
endpoints should end up sending an INVITE with the following as the To
header:
INVITE
.....
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
Point
INVITE
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 SBC
SIP/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: 0
3. Route Point sends REFER to
Customer with Unique Call Identifier attached to Refer-To
field
REFER
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: 0
4. SBC sends INVITE
to B2B UA after parsing Refer-To field of the REFER
message
INVITE 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.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 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/8000
Here 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?
Why 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 multiple
2. 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/