Re: [reSIProcate] how to include "authorization" field in the first "INVITE" sip message

[Scott Godin <sgodin@xxxxxxxxxxxxxxx>]

You cannot provide credentials in an initial request (unless you have already authenticated).  SIP authentication requires you to encode your password using data in the 401 or 407 response.

DUM will handle the authentication (re-creating your invite with authentication headers) for you as long as you have provided authentication information in the MasterProfile or UserProfile (setDigestCredential) passed to the makeInviteSession call.

Scott

On Wed, Oct 2, 2013 at 7:01 PM, Allen Guan <allenguan@xxxxxxxxx> wrote:

Hi, Scott,

Thanks a lot for your prompt reply. I am still kind of new to SIP, so might ask some trivial questions.

I tried to provide credential information in the first INVITE to avoid dealing with the 401 response. Since my application doesn't do registration, so the solution you suggested doesn't work for me.

Now about to dealing with 401 response, the void InviteSessionHandler::onFailure(ClientInviteSessionHandle oClientInviteSessionHandle, const SipMessage& oSipMessage) will be called, I am supposed to reconstruct the INVITE message including the "authorization" field and send it out again. what's the correct way to reconstruct this INVITE message? how the username and password is provided then?

Any comments are welcome, thanks a lot in advance.

-Allen

On Wed, Oct 2, 2013 at 2:52 PM, Scott Godin <sgodin@xxxxxxxxxxxxxxx> wrote:

Hi Allen,

You should be careful about credential caching.  The following rules are in RFC3261 section 22.3:

   The following rule is RECOMMENDED for proxy credential caching:

   If a UA receives a Proxy-Authenticate header field value in a 401/407
   response to a request with a particular Call-ID, it should
   incorporate credentials for that realm in all subsequent requests
   that contain the same Call-ID.  These credentials MUST NOT be cached
   across dialogs; however, if a UA is configured with the realm of its
   local outbound proxy, when one exists, then the UA MAY cache
   credentials for that realm across dialogs.  Note that this does mean
   a future request in a dialog could contain credentials that are not
   needed by any proxy along the Route header path.

DUM will only cache credentials within the same dialog.  I see you are trying to use the setImsAuthUser profile setting - are you really operating in an IMS environment?  I'm not really familiar with how auth works in IMS to help much with it.  

Assuming no IMS - You could try capturing the authorization headers from your last outbound registration (using an outbound decorator - https://www.resiprocate.org/Modifying/Decorating_messages_sent) and placing them in the INVITE after calling makeInviteSession, but make sure you are not violating the RFC statement above.

Scott

On Wed, Oct 2, 2013 at 5:31 PM, Allen Guan <allenguan@xxxxxxxxx> wrote:

Hi, all,

I have a question: I want to include "Authorization" in the first "INVITE" sip message, my code is as follows:
---------
std::string sDialOutUser = DIALOUT_FROM_NUMBER;

NameAddr dialoutAor;
dialoutAor.uri().host() = g_uConferenceConfigure.m_

sExternalIp;
dialoutAor.uri().port() = g_uConferenceConfigure.m_iSIPPort;
dialoutAor.uri().user() = sDialOutUser.c_str();
Data dialoutpasswd("111");

oDialogUsageManager->getMasterProfile()->setDefaultFrom(dialoutAor);
oDialogUsageManager->getMasterProfile()->setDigestCredential(dialoutAor.uri().host(), dialoutAor.uri().user(), dialoutpasswd);
oDialogUsageManager->getMasterProfile()->setImsAuthUser(sDialOutUser.c_str(), oInviteMsgAddr.uri().getAorNoPort());

SharedPtr<SipMessage> inviteMessageUac = oDialogUsageManager->makeInviteSession(oInviteMsgAddr, &oLocalSdp);
--------

the generated sip message's "Authorization" has empty "nonce" and "response", I guess at least "response" should not be empty to include the digest credential information, right? Would you please kindly tell me what's the correct way to do it?

Thanks a lot!

-Allen

_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxx
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel