[Sofia-sip-devel] Multiple Registration support
Hi, using sofia 1.12.10 I have read through the archives various posts on NUTAG_M_USERNAME and NUTAG_IDENTITY and its just confusing. Here's what i want to do, i want my applicationto support registrations with different SIP providers so that it can receive INVITES from different providers at any given time. I currently have no issue getting one working. I create a register handle fill out the from,to , contact headers etc and call nua_register. I notice the stack resolves the DNS address and i get a 401 to which i reply with nua_authenticate and then get a 200. Then i tried with 2 different accounts, one Sipgate the other Callcentric. I created 2 separate register handles and separate call back handlers for each handle. I call nua_register twice with the separate handles now. What i noticed is the REGISTER messages go out to the 2 different providers and i get a 401 back from each one, but my callback handlers are not getting called, its like the stack is not passing these on. I also noticed that the REGISTER messages to the 2 differnet providers are getting sent with the same CSEQ number!!! So i assume the stack is getting completely confused with the responses. I assumed that sending nua_register with separate handles would allow each REGISTER transaction to be treated separately and the responses would be routed to the separate handlers. Can someone give me a high level description how to set up what i want to, as mentioned i have a single account working fine. Regards -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] Duration of Sofia root step interval
Hi, using sofia 1.12.10. How frequently must one call the Sofia root step function. i am currently calling every second. Is this too much? Thanks -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Re: [Sofia-sip-devel] Multiple Registration support
Hi Pekka Yes you were right i had some problem in another part of my code, the method i was using works fine. Just one more thing, how to determine what identity an incoming call is for, as i believe a new handle is created for this? Many Thanks --- On Wed, 14/7/10, Pekka Pessi wrote: From: Pekka Pessi Subject: Re: [Sofia-sip-devel] Multiple Registration support To: nauman762-h...@yahoo.co.uk Cc: sofia-sip-devel@lists.sourceforge.net Date: Wednesday, 14 July, 2010, 16:58 Hi, 2010/7/12 Nauman Sulaiman > > Then i tried with 2 different accounts, one Sipgate the other Callcentric. I > created 2 separate register handles and separate call back handlers for each > handle. I call nua_register twice with the separate handles now. It should work fine, there is probably something else hosed in your code.. > > What i noticed is the REGISTER messages go out to the 2 different providers > and i get a 401 back from each one, but my callback handlers are not getting > called, its like the stack is not passing these on. > I also noticed that the REGISTER messages to the 2 differnet providers are > getting sent with the same CSEQ number!!! So i assume the stack is getting > completely confused with the responses. I assumed that sending nua_register > with separate handles would allow each REGISTER transaction to be treated > separately and the responses would be routed to the separate handlers. The CSeq number is generated based on the current time. Two REGISTERs may have same CSeq as long as their Call-ID header (and tags in From and To headers) are different. > > Can someone give me a high level description how to set up what i want to, as > mentioned i have a single account working fine. It should work just fine, but you can try to enable more detailed debugging logging with NUA_DEBUG=9 and NTA_DEBUG=9 environment variable. -- Pekka.Pessi mail at nokia.com -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://ad.doubleclick.net/clk;226879339;13503038;l? http://clk.atdmt.com/CRS/go/247765532/direct/01/___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] Contact header incorrect
Hi, using Sofia 1.12.10. I have multiple sip accounts, with separate nua handles for each nua_register etc. When i get a nua_i_invite and send a response it seems to pick a contact randomly from sip accounts that i have for the contact header. I am switching on the sip_request field to determine the account the invite is for then i manually attach SIPTAG_CONTACT_STR to each nua_respond etc then all is ok. But is there a better way i should be doing this? Thanks -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://ad.doubleclick.net/clk;226879339;13503038;l? http://clk.atdmt.com/CRS/go/247765532/direct/01/ ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] Using TLS with sofia
Hi, using version 1.12.10. We've compiled OpenSSL 0.9.8, also compiled the 2 source files related to tls in tport. We know that in NUTAG_URL we must pass in transport=tls. What else do we need to do to enable tls on Sofia, is there any sample code to show how to use it? Thanks -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] Multiple transports with single nua_create instance
Hi, using sofi 1.12.10 we have managed t support multiple registrations using separate nua handle to nua_register call, single nua_create call. However is it possible to specify separate ports and transport for each nua_handle OR do we need to create a separate stack instance to support this ie multiple nu_create calls with unique NUTAG_URL for each instance. Ideally we would like to keep a single instance if possible Thanks -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] Using VPN
Hi, using 1.12.10. Sofia doesn't seem to select the vpn ip when connected over VPN. It still seems to be listening on the usual WiFI access point ip, this is the same no matter what ip is passed to NUTAG_URL. How can we tell Sofia to select a certain interface, this is on iphone OS. Thanks -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] su_root_threading query
Hi, using 1.12.10 i've set su_root_threading to multithreading mode. But when i call nua_register for example from the main thread of my app it blocks it, it appears to be all the sresolv stuff. Should this be expected and i should be calling the nua functions on a separate thread. If someone could confirm. Thanks -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] Assertion failed: (b == bend) problem
Hi, Using sofia 1.12.10. We are getting the following assertion in nua_signal after a nua_register call : Assertion failed: (b == bend) What is the purpose of this assertion? Is it saying there is something wrong with any of tag parameters passed to nua_register. Thanks -- Nokia and AT&T present the 2010 Calling All Innovators-North America contest Create new apps & games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] Receiving 500 glare causes Sofia to terminate dialog
Hi, using 1.12.10. I've noticed that Sofia if in established dialog it receives 500 due to invites sent at same time for example both parties put each other on hold simultaneously. Sofia automatically sends a BYE. My understanding of RFC 3261 section 14.1 is that if the UA receives a non 2XX response in established dialog then the session must remain unchanged. It is a Counterpath Bria client sending this 500. Is there someway to prevent sofia terminating here? -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] Where is NUTAG_AUTO302(1)?
Hi, using sofia 1.12.10, couldn't find NUTAG_AUTO302(1) tag. Which version should i be using to use this tag. Thanks -- Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! Tap into the largest installed PC base & get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] Building latest sofia lib from git repo
Hi, I've been using 1.12.10 and as i would like to use the NUTAG_AUTO302 tag i need to use a release from git. So i'm going for the latest master branch. I downloaded the tar.gz file, i'm on mac os snow leopard here. With 1.12.10 i simply used ./configure + make and it built right away. However there is no configure.sh now so i ran autogen and then configure. but now there are errors when i run configure. Its complaining about a GLIB macro. I didn't need to do anything special before so wondering why i'm now missing dependencies. Is this normal or am i missing something? Thanks -- Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! Tap into the largest installed PC base & get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] Populating to header from Refer message with replaces
Hi, using sofia 1.12.10 how to populate TO header of Invite created in response to incoming REFER with refer-to header containing replaces parameter. I can't just use the refer-to uri on its own as it has the all the replaces stuff. I suppose i could grab the various bits from the refer-to header and create a To uri but was wondering if there is a better way. I am currently using the following tags SIPTAG_FROM_STR SIPTAG_TO_STR NUTAG_URL NUTAG_NOTIFY_REFER NUTAG_REFER_EVENT the new invite is being created with a replaces header, just the to header is wrong -- What happens now with your Lotus Notes apps - do you make another costly upgrade, or settle for being marooned without product support? Time to move off Lotus Notes and onto the cloud with Force.com, apps are easier to build, use, and manage than apps on traditional platforms. Sign up for the Lotus Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] Disabling REFER autorespond in Sofia - side issue
Hi, using Sofia 1.12.10. If i disable autorespond 202 for incoming refer
like this NUTAG_APPL_METHOD("REFER")
So i handle the 202 myself like this
nua_respond(nh, SIP_202_ACCEPTED, NUTAG_WITH_CURENT(nua), TAG_END());
But then when i try to save the event handle of the refer so i can pass to
outgoing invite with replaces (so i get autosend of NOTIFYs)
sip_event_t const *event = NULL;
tl_gets(tags, NUTAG_REFER_EVENT_REF(event), TAG_END());
THe event is NULL, this time. I think its because i did the nua_respond.
Anyone know how to get this to work.
Everything was working fine with autorespond of the refer but i need to disable
this.
Thanks
--
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] Register WWW-Authenticate header 'qop' missing
Hi, using 1.12.10 sofia. If one receives a challenge to register request I currently reply with nua_authenticate(NUTAG_AUTH()) However if the challenge had the 'qop' parameter then this does not get copied to the response sent by nua_authenticate. Plus no 'nc' parameter. how do i add these to the response?? Thanks -- Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] Is CLRF UDP keepalive supported in sofia sip
Hi, have noticed there is a TCP CLRF keepalive. Was wondering if there is equivalent UDP? Thanks -- Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Re: [Sofia-sip-devel] Register WWW-Authenticate header 'qop' missing
Please ignore previous message, i was talking rubbish :) qop is there of course --- On Sat, 8/1/11, Nauman Sulaiman wrote: > From: Nauman Sulaiman > Subject: [Sofia-sip-devel] Register WWW-Authenticate header 'qop' missing > To: sofia-sip-devel@lists.sourceforge.net > Date: Saturday, 8 January, 2011, 17:52 > Hi, using 1.12.10 sofia. If one > receives a challenge to register request I currently reply > with nua_authenticate(NUTAG_AUTH()) > > However if the challenge had the 'qop' parameter then this > does not get copied to the response sent by > nua_authenticate. Plus no 'nc' parameter. how do i add these > to the response?? > > Thanks > > > > > -- > Gaining the trust of online customers is vital for the > success of any company > that requires sensitive data to be transmitted over the > Web. Learn how to > best implement a security strategy that keeps consumers' > information secure > and instills the confidence they need to proceed with > transactions. > http://p.sf.net/sfu/oracle-sfdevnl > ___ > Sofia-sip-devel mailing list > Sofia-sip-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel > -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] Turning off tport bad message error
Hi, Using the latest git master version. I keep getting the following error. How do i stop it from happening and also how to turn off the log. Setting TPORT_DEBUG to 0 did not help. "nta_agent:tport:Bad message" Many thanks -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] Incoming REFER , how does app receive status of NOTIFYs
Hi, Using latest Sofia master from git. When i get an incoming REFER the stack sends NOTIFY's to the referror if i pass the event to the INVITE i generate. This works very nicely. But how does the app know what NOTIFY's are being sent to the referror ie i would like to get hold of the Sipfrag, event nua_r_notify or nua_i|_state are both no good. So i need to know when 180 ringing is being sent, or if the Invite generated failed eg with 486 etc. Thanks -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Re: [Sofia-sip-devel] Turning off tport bad message error
Please ignore previous message, this error message is error condition so desn't appear to be under control of Environment variables, --- On Wed, 9/2/11, Nauman Sulaiman wrote: > From: Nauman Sulaiman > Subject: [Sofia-sip-devel] Turning off tport bad message error > To: sofia-sip-devel@lists.sourceforge.net > Date: Wednesday, 9 February, 2011, 23:32 > Hi, Using the latest git master > version. I keep getting the following error. > How do i stop it from happening and also how to turn off > the log. > > Setting TPORT_DEBUG to 0 did not help. > > "nta_agent:tport:Bad message" > > Many thanks > > > > > -- > The ultimate all-in-one performance toolkit: Intel(R) > Parallel Studio XE: > Pinpoint memory and threading errors before they happen. > Find and fix more than 250 security defects in the > development cycle. > Locate bottlenecks in serial and parallel code that limit > performance. > http://p.sf.net/sfu/intel-dev2devfeb > ___ > Sofia-sip-devel mailing list > Sofia-sip-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel > -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] NOTIFY sip frag set to 503 when receiving 407 Invite response
Hi, when performing an attended transfer, when the transfer destination sends a
407 to the INVITE with replaces generated by transferee, a NOTIFY with 503
sipfrag is sent to the transferrer. Code is here in nua_session.c
in function nh_referral_respond. The transfer destination is in different
domain. The resulting NOTIFY 503 sent to the transferrer makes him think the
transfer has failed rather than just being in progress. Is there some reason
for this or is it a bug?
if (status >= 300)
status = 503, phrase = sip_503_Service_unavailable;
snprintf(payload, sizeof(payload), "SIP/2.0 %03u %s\r\n", status, phrase);
if (status < 200)
substate = "active";
else
substate = "terminated ;reason=noresource";
nua_stack_post_signal(ref->ref_handle,
nua_r_notify,
SIPTAG_EVENT(ref->ref_event),
SIPTAG_SUBSCRIPTION_STATE_STR(substate),
SIPTAG_CONTENT_TYPE_STR("message/sipfrag"),
SIPTAG_PAYLOAD_STR(payload),
TAG_END());
Regards
--
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] How to know when to send PRACK?
Hi, To use PRACK in our application we set 100rel as supported in outgoing INVITE. However to know whether to use nua_prack as response to a 18X, does the application have to always check the Require header in a 18X to see if it has 100rel or is there some other we should be doing it? Also if incoming INVITE has 100rel must we check the supported header before sending a 18X response reliably? Any link to sample code would be useful. Thanks -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] PRACK and 200 OK(INVITE) forking issue
Hi, using Sofia 1.12.11
We have the following flow
UAC UAS
-->
INVITE
<--
183 rel
--->
PRACK
<---
200OK
<---
200 OK (different To tag to 183 above)
--->
ACK
--->
BYE
On the 200 OK to the Invite, if it has different To tag to the 183
Sofia thinks its orphan 200 final response and discards. This is the code
that causes this. This only happens when PRACK is involved. If the INVITE is
sent without support for 100 rel all is ok
if (orq->orq_destroyed && 200 <= status && status < 300) {
if (orq->orq_uas && su_strcasecmp(sip->sip_to->a_tag, orq->orq_tag) != 0)
{
/* Orphan 200 Ok to INVITE. ACK and BYE it */
SU_DEBUG_5(("nta: Orphan 200 Ok send ACK&BYE\n"));
return nta_msg_ackbye(sa, msg);
}
return -1; /* Proxy statelessly (RFC3261 section 16.11) */
}
It looks like the orq_destroyed bit is set which is causing this. Is the fork
of the 200OK not regarded as existing INVITE transaction. Any pointers
to help solve this most appreciated.
Thanks
--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Re: [Sofia-sip-devel] How to know when to send PRACK?
Please ignore this, we can just check if there is a REQUIRE 100rel header in the 18x response --- On Sat, 25/6/11, Nauman Sulaiman wrote: > From: Nauman Sulaiman > Subject: [Sofia-sip-devel] How to know when to send PRACK? > To: sofia-sip-devel@lists.sourceforge.net > Date: Saturday, 25 June, 2011, 18:55 > Hi, To use PRACK in our application > we set 100rel as supported in outgoing INVITE. However to > know whether to use nua_prack as response to a 18X, > does the application have to always check the Require > header in a 18X to see if it has 100rel or is there some > other we should be doing it? > > Also if incoming INVITE has 100rel must we check the > supported header before sending a 18X response reliably? Any > link to sample code would be useful. > > Thanks > > -- > All the data continuously generated in your IT > infrastructure contains a > definitive record of customers, application performance, > security > threats, fraudulent activity and more. Splunk takes this > data and makes > sense of it. Business sense. IT sense. Common sense.. > http://p.sf.net/sfu/splunk-d2d-c1 > ___ > Sofia-sip-devel mailing list > Sofia-sip-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel > -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Re: [Sofia-sip-devel] PRACK and 200 OK(INVITE) forking issue
Hi,
Got a bit further with this, reason that the 200OK ( to INVITE) is being
discarded is because of this code :
static int nua_invite_client_preliminary(nua_client_request_t *cr,
int status, char const *phrase,
sip_t const *sip)
{
nua_handle_t *nh = cr->cr_owner;
nua_dialog_usage_t *du = cr->cr_usage;
nua_session_usage_t *ss = nua_dialog_usage_private(du);
assert(sip);
if (ss && sip && sip->sip_rseq) {
/* Handle 100rel responses */
sip_rseq_t *rseq = sip->sip_rseq;
/* Establish early dialog - we should fork here */
if (!nua_dialog_is_established(nh->nh_ds)) {
nta_outgoing_t *tagged;
nua_dialog_uac_route(nh, nh->nh_ds, sip, 1, 1);
nua_dialog_store_peer_info(nh, nh->nh_ds, sip);
/* Tag the INVITE request */
tagged = nta_outgoing_tagged(cr->cr_orq,
nua_client_orq_response, cr,
sip->sip_to->a_tag, sip->sip_rseq);
if (tagged) {
nta_outgoing_destroy(cr->cr_orq), cr->cr_orq = tagged;
}
else {
cr->cr_graceful = 1;
ss->ss_reason = "SIP;cause=500;text=\"Cannot Create Early Dialog\"";
}
}
When we get a 183 reliable response Sofia creates an early dialog and creates a
new tagged INVITE request
if (tagged) {
nta_outgoing_destroy(cr->cr_orq)
It looks like it marks the original request for destruction, the problem is
when a 200OK comes in with a different tag, it looks as if its matched against
the original transaction which is marked for destruction and so is discarded by
the code I posted initially in outgoing_recv in nta.c
We are handling all media (SDP) ourselves and have set PRACK to be one of the
methods our app handles. We are using the nua API.
Can Pekka or someone say whether PRACK and forking is supported with the way
we are using the Stack. We've seen some posts saying there are various bugs.
When PRACK is not used the first 200OK received is passed to the application
with cancel sent to the others. This is the behaviour we would like even when
PRACK is used. However it seems that when the first 183 reliable is received
this results in subsequent 200OK from other forks to be discarded. We just want
the first 200OK final response to be passed to our application irrespective of
which fork its from and are happy for CANCEL to be sent to others.
Any comments most appreciated.
Thanks
--- On Wed, 29/6/11, Nauman Sulaiman wrote:
> From: Nauman Sulaiman
> Subject: [Sofia-sip-devel] PRACK and 200 OK(INVITE) forking issue
> To: sofia-sip-devel@lists.sourceforge.net
> Date: Wednesday, 29 June, 2011, 23:06
> Hi, using Sofia 1.12.11
>
> We have the following flow
>
>
> UAC
> UAS
> -->
> INVITE
> <--
> 183 rel
> --->
> PRACK
> <---
> 200OK
>
> <---
> 200 OK (different To tag to 183
> above)
>
> --->
> ACK
> --->
> BYE
>
>
> On the 200 OK to the Invite, if it has different To tag to
> the 183
> Sofia thinks its orphan 200 final response and discards.
> This is the code
> that causes this. This only happens when PRACK is involved.
> If the INVITE is sent without support for 100 rel all is ok
>
>
> if (orq->orq_destroyed && 200 <= status
> && status < 300) {
> if (orq->orq_uas &&
> su_strcasecmp(sip->sip_to->a_tag, orq->orq_tag) !=
> 0) {
> /* Orphan 200 Ok to INVITE. ACK
> and BYE it */
> SU_DEBUG_5(("nta: Orphan 200 Ok
> send ACK&BYE\n"));
> return nta_msg_ackbye(sa,
> msg);
> }
> return -1; /* Proxy statelessly
> (RFC3261 section 16.11) */
> }
>
>
> It looks like the orq_destroyed bit is set which is causing
> this. Is the fork of the 200OK not regarded as existing
> INVITE transaction. Any pointers
> to help solve this most appreciated.
>
> Thanks
>
> --
> All of the data generated in your IT infrastructure is
> seriously valuable.
> Why? It contains a definitive record of application
> performance, security
> threats, fraudulent activity, and more. Splunk takes this
> data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> ___
> Sofia-sip-devel mailing list
> Sofia-sip-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/sof
[Sofia-sip-devel] Using sips: AND sip:ip;transport=tls with Sofia
Hi, We have managed to get TLS working with Sofia by specifying a sips uri with NUTAG_URL however the other way sip:ip;transport=tls is still widely used and we would like to know how to use this with Sofia. How can we get Sofia to use TLS transport with a sip uri. Passing sip:ip;transport=tls into NUTAG_URL or NUTAG_SIPS_URL is no good as the stack says that tls is not a recognised transport. If anyone knows the answer, please. Thanks -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] Sofia as UA keeps losing TLS connection with Asterisk 1.8.7
Hi, We are using Sofia SIP 1.12.11 as UA with Asterisk 1.8.7 using TLS. It registers OK but then keeps losing its connection and seems to keep registering every 30 seconds. We have tried other clients such as Bria and these work fine with TLS to our Asterisk 1.8.7 server so its something to do with our Sofia client. The Sofia client works fine with TCP with same Asterisk 1.8.7 server. Trace is below, Sofia seems to get a HUP event which makes it lose its connection, anybody any ideas how to make Sofia keep the TLS connection open THanks - nua: nua_stack_init: entering nua: nua_stack_set_params: entering nta_agent_create: initialized hash tables nta_agent_create: initialized transports nta_agent_create: initialized random identifiers nta_agent_create: initialized timer tport_tls_writevec: vec 0x4676c80 0xb6f200 581 (581) tport_vsend returned 581 tport(0x4687d80): reset timer nta: sent SUBSCRIBE (18216628) to TLS/178.76.132.10:5061 tport_pend(0x4687d80): pending 0x4665030 for tls/178.76.132.10:5061 (already 0) nua(0x4673cd0): removing subscribe usage with event message-summary nta_leg_destroy(0x468bc80) nta_leg_destroy(0x0) nua: nua_stack_shutdown: entering nta: outgoing_free(0x4664520) tport_release(0x4687d80): 0x4665030 by 0x4664520 with 0x0 tport(0x4687d80): set timer at 1799987 ms because idle since send sres_sofia_update(0x7998a0, -1, -1) sres_sofia_update(0x0, -1, -1) tport_destroy(0x4688af0) nta_agent_create: initialized resolver tport_create(): 0x465eb10 nta: master transport created tport_bind_server(0x465eb10) to */192.168.1.100:10131/sips tport_bind_server(0x465eb10): calling tport_listen for tls tport_alloc_primary(0x465eb10): new primary tport 0x465af70 tport_tls_init_master(0x465af70): tls context initialized for 192.168.1.100 tport_listen(0x465af70): listening at tls/192.168.1.100:10131/sips nta: bound to (192.168.1.100:10131;transport=*) nta: agent_init_via: SIP/2.0/tls 192.168.1.100:10131 (sips) nta: Via fields initialized nta: Contact header created nua_register: Adding contact URL '192.168.1.100' to list. nua: nua_set_params: entering nua(0x0): sent signal r_set_params nua: nh_create_handle: entering nua: nua_set_hparams: entering nua(0x7b5040): sent signal r_set_params nua: nh_create_handle: entering nua: nua_set_hparams: entering nua(0x46937b0): sent signal r_set_params nua: nua_register: entering nua(0x7b5040): sent signal r_register nua: nua_subscribe: entering nua(0x46937b0): sent signal r_subscribe nua: nua_application_event: entering nua: nua_destroy: entering nua: nua_stack_deinit: entering su_kqueue_port_deinit(0x4666c90) called nua: nua_stack_set_params: entering nua: nua_stack_set_params: entering nua: nua_stack_set_params: entering nua: nua_stack_set_params: entering nua(0x7b5040): adding register usage nta_leg_tcreate(0x4687030) nta: selecting scheme sips tport_tsend(0x465af70) tpn = tls/178.76.132.10:5061 tport_resolve addrinfo = 178.76.132.10:5061 tport_by_addrinfo(0x465af70): not found by name tls/178.76.132.10:5061 tport_alloc_secondary(0x465af70): new secondary tport 0x7dea60 tport_tls_connect(0x7dea60): connecting to tls/178.76.132.10:5061/sips tport(0x7dea60): reset timer tport_queue(0x7dea60): queueing 0x46930c0 for tls/178.76.132.10:5061 nta: sent REGISTER (18216632) to tls/178.76.132.10:5061 tport_pend(0x7dea60): pending 0x46930c0 for tls/178.76.132.10:5061 (already 0) nta: timer set to 32000 ms nua: nua_stack_set_params: entering nua(0x46937b0): adding subscribe usage with event message-summary nta_leg_tcreate(0x7e62e0) nta: selecting scheme sip tport_tsend(0x465af70) tpn = */178.76.132.10:5061 tport_resolve addrinfo = 178.76.132.10:5061 tport_by_addrinfo(0x465af70): found 0x7dea60 by name */178.76.132.10:5061 tport_queue(0x7dea60): queueing 0x4694db0 for tls/178.76.132.10:5061 nta: sent SUBSCRIBE (18216632) to */178.76.132.10:5061 tport_pend(0x7dea60): pending 0x4694db0 for tls/178.76.132.10:5061 (already 1) tls_connect(0x7dea60): events CONNECTING nua: nua_application_event: entering nua: nua_application_event: entering nua: nua_application_event: entering tls_connect(0x7dea60): events NEGOTIATING tls_connect(0x7dea60): events NEGOTIATING tport_send_event(0x7dea60) - ready to send to (tls/178.76.132.10:5061) tport_tls_writevec: vec 0x465ba60 0xb5ca00 485 (485) tport_vsend returned 485 tport_tls_writevec: vec 0x465ba60 0xb71200 545 (545) tport_vsend returned 545 tport_tls_set_events(0x7dea60): logical events IN real IN tport(0x7dea60): reset timer tport_wakeup(0x7dea60): events IN tport_recv_event(0x7dea60) tport_tls_recv(0x7dea60): tls_read() returned 527 tport_recv_iovec(0x7dea60) msg 0x4662050 from (tls/178.76.132.10:5061) has 527 bytes, veclen = 1 tport_deliver(0x7dea60): msg 0x4662050 (527 bytes) from tls/178.76.132.10:5061/sips next=0x0 nta: received 401 Unauthorized for REGISTER (18216632) nta: 401 Unauthorized is going to a transaction nta_outgoing: RTT is 272.915 ms tport_
Re: [Sofia-sip-devel] PRACK and 200 OK(INVITE) forking issue
Hi Timo
No we don't have a solution, we looked into it and it needs major changes so we
left it.
Regards
From: Timo Bruhn
To: nauman762-h...@yahoo.co.uk
Cc: sofia-sip-devel@lists.sourceforge.net
Sent: Wednesday, 14 March 2012, 11:04
Subject: Re: [Sofia-sip-devel] PRACK and 200 OK(INVITE) forking issue
Hi Nauman,
did you find a solution for the problem when forking is combined with PRACK?
Currently we are running into same problems with sofia-sip connecting to a
server that uses forking.
Seems that disabling PRACK and soa engine works. But what if PRACK is required?
Thanks,
Timo
> Hi,
>
> Got a bit further with this, reason that the 200OK ( to INVITE) is being
> discarded is because of this code :
>
> static int nua_invite_client_preliminary(nua_client_request_t *cr,
> int status, char const *phrase,
> sip_t const *sip)
> {
> nua_handle_t *nh = cr->cr_owner;
> nua_dialog_usage_t *du = cr->cr_usage;
> nua_session_usage_t *ss = nua_dialog_usage_private(du);
>
> assert(sip);
>
> if (ss && sip && sip->sip_rseq) {
> /* Handle 100rel responses */
> sip_rseq_t *rseq = sip->sip_rseq;
>
> /* Establish early dialog - we should fork here */
> if (!nua_dialog_is_established(nh->nh_ds)) {
> nta_outgoing_t *tagged;
>
> nua_dialog_uac_route(nh, nh->nh_ds, sip, 1, 1);
> nua_dialog_store_peer_info(nh, nh->nh_ds, sip);
>
> /* Tag the INVITE request */
> tagged = nta_outgoing_tagged(cr->cr_orq,
> nua_client_orq_response, cr,
> sip->sip_to->a_tag, sip->sip_rseq);
> if (tagged) {
> nta_outgoing_destroy(cr->cr_orq), cr->cr_orq = tagged;
> }
> else {
> cr->cr_graceful = 1;
> ss->ss_reason = "SIP;cause=500;text=\"Cannot Create Early Dialog\"";
> }
> }
>
>
> When we get a 183 reliable response Sofia creates an early dialog and creates
> a new tagged INVITE request
>
> if (tagged) {
> nta_outgoing_destroy(cr->cr_orq)
>
> It looks like it marks the original request for destruction, the problem is
> when a 200OK comes in with a different tag, it looks as if its matched
> against the original transaction which is marked for > destruction and so is
> discarded by the code I posted initially in outgoing_recv in nta.c
>
>
> We are handling all media (SDP) ourselves and have set PRACK to be one of the
> methods our app handles. We are using the nua API.
>
> Can Pekka or someone say whether PRACK and forking is supported with the way
> we are using the Stack. We've seen some posts saying there are various bugs.
>
> When PRACK is not used the first 200OK received is passed to the application
> with cancel sent to the others. This is the behaviour we would like even when
> PRACK is used. However it seems > that when the first 183 reliable is
> received this results in subsequent 200OK from other forks to be discarded.
> We just want the first 200OK final response to be passed to our application >
> irrespective of which fork its from and are happy for CANCEL to be sent to
> others.
>
> Any comments most appreciated.
> Thanks
>
___
Ihr WEB.DE Postfach immer dabei: die kostenlose WEB.DE Mail App für iPhone und
Android.
https://produkte.web.de/freemail_mobile_startseite/--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
