While sending a call to the Park Server via consultative transfer, I notice that after the Park Server receives the second INVITE (with Replaces, from the parkee, replacing the first INVITE from the parker), the Park Server cannot get the request-URI. The code it uses is:
Initial processing of the TAO message:
if (rMsg.getMsgType() == OsMsg::TAO_MSG &&
rMsg.getMsgSubType() == TaoMessage::EVENT)
{
TaoMessage* taoMessage = (TaoMessage*)&rMsg;
int taoEventId = taoMessage->getTaoObjHandle();
UtlString argList(taoMessage->getArgList());
TaoString arg(argList, TAOMESSAGE_DELIMITER);
if (OsSysLog::willLog(FAC_PARK, PRI_DEBUG))
{
// Dump the contents of the Tao message.
dumpTaoMessageArgs(taoEventId, arg) ;
}
UtlBoolean localConnection = atoi(arg[TAO_OFFER_PARAM_LOCAL_CONNECTION]);
UtlString callId = arg[TAO_OFFER_PARAM_CALLID] ;
UtlString address = arg[TAO_OFFER_PARAM_ADDRESS] ;
Separating the CONNECTION_ESTABLISHED messages:
case PtEvent::CONNECTION_ESTABLISHED:
if (localConnection)
{
OsSysLog::add(FAC_PARK, PRI_DEBUG, "OrbitListener::handleMessage - Call established: callId '%s', address: '%s'",
callId.data(), address.data());
ParkedCallObject* pThisCall = NULL;
// CallId at this point is either the callId of a normal call or the original callId
// of a second leg of a transfer.
// Test if this is a call retrieval operation
if (!isCallRetrievalInvite(callId.data(), address.data()))
Determining the request URI of the message:
bool OrbitListener::isCallRetrievalInvite(const char* callId,
const char* address)
{
bool bRet = false;
// Retrieve the request URI
SipDialog dialog;
mpCallManager->getSipDialog(callId,
address,
dialog);
UtlString request;
dialog.getRemoteRequestUri(request);
OsSysLog::add(FAC_PARK, PRI_DEBUG, "OrbitListener::isCallRetrievalInvite remote request URI %s", request.data());
The typical log contents are:
"2006-09-15T19:56:06.584938Z":323:INCOMING:"Read SIP message:\n----Remote Host:10.1.1.68---- Port: 53303----\nINVITE sip:
700@10.1.1.68:5120 SIP/2.0\r\nRecord-Route: <sip:10.1.1.68:5080;lr>\r\nVia: SIP/2.0/UDP 10.1.1.68:5080;branch=z9hG4bK-e1aae37cfe362a88749ba06be0f18532\r\nVia: SIP/2.0/UDP 10.1.1.68;branch=z9hG4bK-526cdd4a1e699b38d953772abd0db7b8\r\nVia: SIP/2.0/UDP 10.1.1.41;branch=z9hG4bK710d03ca1B72A6B9\r\nFrom: \"222\" <sip:
222@niagra.pingtel.com>;tag=C270DB28-5ED4F76D\r\nTo: <sip:
700@niagra.pingtel.com>\r\nCseq: 1 INVITE\r\nCall-Id:
a0f5a0a4-5c3f94ee-5c70ea7b@10.1.1.41\r\nContact: <sip:
222@10.1.1.41>\r\nAllow: INVITE, ACK, BYE, CANCEL, OPTIONS, INFO, MESSAGE, SUBSCRIBE, NOTIFY, PRACK, UPDATE, REFER\r\nUser-Agent: PolycomSoundPointIP-SPIP_301-UA/2.0.0.1950\r\nSupported: 100rel,replaces\r\nAllow-Events: talk,hold,conference\r\nReplaces:
6e95f1ef-9c3e7c6d-77d44b06@10.1.1.44;to-tag=1684785607;from-tag=BB6742B-3093D524\r\nReferred-By: <sip:
111@niagra.pingtel.com>\r\nMax-Forwards: 18\r\nContent-Type: application/sdp\r\nContent-Length: 241\r\nDate: Fri, 15 Sep 2006 19:56:06 GMT\r\n\r\nv=0\r\no=- 978498820 978498820 IN IP4 10.1.1.41\r\ns=Polycom IP Phone\r\nc=IN IP4 10.1.1.41\r\nt=0 0\r\na=sendrecv\r\nm=audio 2236 RTP/AVP 0 8 18 101\r\na=rtpmap:0 PCMU/8000\r\na=rtpmap:8 PCMA/8000\r\na=rtpmap:18 G729/8000\r\na=rtpmap:101 telephone-event/8000\r\n====================END====================\n"
"2006-09-15T19:56:06.587957Z":325:OUTGOING:"SipUserAgent::sendUdp UDP SIP User Agent sent message:\n----Remote Host:10.1.1.68---- Port: 5080----\nSIP/2.0 100 Trying\r\nFrom: \"222\" <sip:
222@niagra.pingtel.com>;tag=C270DB28-5ED4F76D\r\nTo: <sip:
700@niagra.pingtel.com>\r\nCall-Id:
a0f5a0a4-5c3f94ee-5c70ea7b@10.1.1.41\r\nCseq: 1 INVITE\r\nVia: SIP/2.0/UDP 10.1.1.68:5080;branch=z9hG4bK-e1aae37cfe362a88749ba06be0f18532\r\nVia: SIP/2.0/UDP 10.1.1.68;branch=z9hG4bK-526cdd4a1e699b38d953772abd0db7b8\r\nVia: SIP/2.0/UDP 10.1.1.41;branch=z9hG4bK710d03ca1B72A6B9\r\nContent-Length: 0\r\n\r\n--------------------END--------------------\n"
"2006-09-15T19:56:06.588120Z":326:INCOMING_PARSED:"INVITE sip:
700@10.1.1.68:5120 SIP/2.0\r\nRecord-Route: <sip:10.1.1.68:5080;lr>\r\nVia: SIP/2.0/UDP 10.1.1.68:5080;branch=z9hG4bK-e1aae37cfe362a88749ba06be0f18532\r\nVia: SIP/2.0/UDP 10.1.1.68;branch=z9hG4bK-526cdd4a1e699b38d953772abd0db7b8\r\nVia: SIP/2.0/UDP 10.1.1.41;branch=z9hG4bK710d03ca1B72A6B9\r\nFrom: \"222\" <sip:
222@niagra.pingtel.com>;tag=C270DB28-5ED4F76D\r\nTo: <sip:
700@niagra.pingtel.com>\r\nCseq: 1 INVITE\r\nCall-Id:
a0f5a0a4-5c3f94ee-5c70ea7b@10.1.1.41\r\nContact: <sip:
222@10.1.1.41>\r\nAllow: INVITE, ACK, BYE, CANCEL, OPTIONS, INFO, MESSAGE, SUBSCRIBE, NOTIFY, PRACK, UPDATE, REFER\r\nUser-Agent: PolycomSoundPointIP-SPIP_301-UA/2.0.0.1950\r\nSupported: 100rel,replaces\r\nAllow-Events: talk,hold,conference\r\nReplaces:
6e95f1ef-9c3e7c6d-77d44b06@10.1.1.44;to-tag=1684785607;from-tag=BB6742B-3093D524\r\nReferred-By: <sip:
111@niagra.pingtel.com>\r\nMax-Forwards: 18\r\nContent-Type: application/sdp\r\nContent-Length: 241\r\nDate: Fri, 15 Sep 2006 19:56:06 GMT\r\n\r\nv=0\r\no=- 978498820 978498820 IN IP4 10.1.1.41\r\ns=Polycom IP Phone\r\nc=IN IP4 10.1.1.41\r\nt=0 0\r\na=sendrecv\r\nm=audio 2236 RTP/AVP 0 8 18 101\r\na=rtpmap:0 PCMU/8000\r\na=rtpmap:8 PCMA/8000\r\na=rtpmap:18 G729/8000\r\na=rtpmap:101 telephone-event/8000\r\n++++++++++++++++++++END++++++++++++++++++++\n"
"2006-09-15T19:56:06.674305Z":346:OUTGOING:"SipUserAgent::sendUdp UDP SIP User Agent sent message:\n----Remote Host:10.1.1.68---- Port: 5080----\nSIP/2.0 200 OK\r\nFrom: \"222\" <sip:
222@niagra.pingtel.com>;tag=C270DB28-5ED4F76D\r\nTo: <sip:
700@niagra.pingtel.com>;tag=1308818197\r\nCall-Id:
a0f5a0a4-5c3f94ee-5c70ea7b@10.1.1.41\r\nCseq: 1 INVITE\r\nContact: sip:10.1.1.68:5120\r\nContent-Type: application/sdp\r\nContent-Length: 190\r\nVia: SIP/2.0/UDP 10.1.1.68:5080;branch=z9hG4bK-e1aae37cfe362a88749ba06be0f18532\r\nVia: SIP/2.0/UDP 10.1.1.68;branch=z9hG4bK-526cdd4a1e699b38d953772abd0db7b8\r\nVia: SIP/2.0/UDP 10.1.1.41;branch=z9hG4bK710d03ca1B72A6B9\r\nRecord-Route: <sip:10.1.1.68:5080;lr>\r\nDate: Fri, 15 Sep 2006 19:56:06 GMT\r\nAllow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE\r\nUser-Agent: sipX/3.5.0 (Linux)\r\nAccept-Language: en\r\nSupported: replaces\r\n\r\nv=0\r\no=sipX 5 6 IN IP4 10.1.1.68\r\ns=phone-call\r\nc=IN IP4 10.1.1.68\r\nt=0 0\r\nm=audio 8002 RTP/AVP 0 8 101\r\na=rtpmap:0 pcmu/8000/1\r\na=rtpmap:8 pcma/8000/1\r\na=rtpmap:101 telephone-event/8000/1\r\n--------------------END--------------------\n"
"2006-09-15T19:56:06.675326Z":349:APACHE_AUTH:"OrbitListener::dumpTaoMessageArgs Tao event id: 602 local: 1 args: 13"
"2006-09-15T19:56:06.675693Z":364:APACHE_AUTH:"OrbitListener::dumpTaoMessageArgs Tao event id: 206 local: 1 args: 13"
"2006-09-15T19:56:06.675981Z":378:APACHE_AUTH:"OrbitListener::handleMessage - Call established: callId '
6e95f1ef-9c3e7c6d-77d44b06@10.1.1.44', address: '\"222\"<sip:
222@niagra.pingtel.com>;tag=C270DB28-5ED4F76D'"
"2006-09-15T19:56:06.711747Z":396:OUTGOING:"SipUserAgent::sendUdp UDP SIP User Agent sent message:\n----Remote Host:10.1.1.68---- Port: 5080----\nBYE sip:
111@10.1.1.44:5060 SIP/2.0\r\nRoute: <sip:10.1.1.68:5080;lr>\r\nFrom: <sip:
700@niagra.pingtel.com;user=phone>;tag=1684785607\r\nTo: \"111\" <sip:
111@niagra.pingtel.com>;tag=BB6742B-3093D524\r\nCall-Id:
6e95f1ef-9c3e7c6d-77d44b06@10.1.1.44\r\nCseq: 1 BYE\r\nContact: sip:10.1.1.68:5120\r\nDate: Fri, 15 Sep 2006 19:56:06 GMT\r\nMax-Forwards: 20\r\nUser-Agent: sipX/3.5.0 (Linux)\r\nAccept-Language: en\r\nSupported: replaces\r\nVia: SIP/2.0/UDP 10.1.1.68:5120;branch=z9hG4bK-dc4b6c64792a7fba8aef578ea0310b15\r\nContent-Length: 0\r\n\r\n--------------------END--------------------\n"
"2006-09-15T19:56:06.762696Z":404:APACHE_AUTH:"OrbitListener::isCallPickupInvite remote request URI ''"
> I think this is the underlying technical reason why if you cons. transf.
> a call to the Park Server, the Park Server cannot transfer it back to the original callee.
> If we want to fix that feature problem for 3.8, we'll probably have to fix this issue.
Put this on the 3.8 list.