Re: [Sofia-sip-devel] OPTIONS keep-alive broken?

[mikhail.zabaluev]

Classification: Company Confidential

Hi,

> -Original Message-
> From: ext voip_v...@web.de [mailto:voip_v...@web.de]
> Sent: 15 June, 2011 11:24
> To: Sofia-Sip-Devel
> Subject: Re: [Sofia-sip-devel] OPTIONS keep-alive broken?
> 
> >> after updating to sofia-sip 1.12.11 I am facing some problems with 
> >> NAT keep- alive via options packets. NUA is configured to send 
> >> these packets every 15 seconds, but they are sent in an interval of 
> >> about 500ms. In fact sofia is retransmitting the packets, although 
> >> answers are correctly received. I have seen this behaviour at 
> >> different sites with
> different SIP providers.
> >>
> >> Downgrading to 1.12.10 helps, packets are sent every 15 seconds.
> >>
> >> I attach sofia log files (one of 1.12.11 and one of 1.12.10) to 
> >> this mail. In both logs a nua object is created and the ua 
> >> registers with the german sip provider sipgate. After successful 
> >> registration options
> keep-alive is started.
> >>
> >> The logs are almost identical until the first answer to an options 
> >> keep-alive is received (around line 140). In sofia 1.12.10 register 
> >> and options transactions are destroyed after timer k has been fired.
> >> In sofia 1.12.11 this is missing and the options packet is almost
> immediately resent.
> >>
> >> Is this a known bug or has anyone else seen this behaviour?
> >
> >Can you check with the latest build off the trunk?
> >Also please check with a more realistic keep-alive period, 15 seconds 
> >is a bit
> extreme anyway...
> >
> Thanks for your reply. I tried the latest build which shows the same 
> behaviour.
> 
> Your hint about the keep-alive period seems to point into the right direction.
> Using a keep-alive period of around 35 seconds packets are sent correctly.
> But if i use smaller periods, packets are sent much too fast (30 
> seconds lead to a real period of 20 seconds, 18 seconds to 3 seconds 
> and
> 15 seconds or lower to an immediate resent of the options packet).
> 
> I checked this against 1.12.10 release again, where small keep-alive 
> periods work perfectly.
> 
> Although I agree that 15 seconds are very fast, I would like to fix 
> this problem.  Do you have any pointer into the code?

You can start with nua/outbound.c, the code setting the timer. I recently 
submitted some changes in timer scheduling, and I have to admit that extremely 
tight refresh periods were not considered an important use case.
As a simpler solution, you can try making all timers non-deferrable through a 
newly available tag, if the battery life is not a concern (as you wish to send 
pings every 15 seconds, it's probably not something that worries you :-)).

Best regards,
  Mikhail

Classification: Company Confidential
--
AppSumo Presents a FREE Video for the SourceForge Community by Eric 
Ries, the creator of the Lean Startup Methodology on "Lean Startup 
Secrets Revealed." This video shows you how to validate your ideas, 
optimize your ideas and identify your business strategy.
http://p.sf.net/sfu/appsumosfdev2dev
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] OPTIONS keep-alive broken?

[mikhail.zabaluev]

Hi,

> -Original Message-
> From: ext Timo Bruhn [mailto:voip_v...@web.de]
> Sent: 25 May, 2011 10:14
> To: sofia-sip-devel@lists.sourceforge.net
> Subject: [Sofia-sip-devel] OPTIONS keep-alive broken?
> 
> Hi,
> 
> after updating to sofia-sip 1.12.11 I am facing some problems with NAT keep-
> alive via options packets. NUA is configured to send these packets every 15
> seconds, but they are sent in an interval of about 500ms. In fact sofia is
> retransmitting the packets, although answers are correctly received. I have
> seen this behaviour at different sites with different SIP providers.
> 
> Downgrading to 1.12.10 helps, packets are sent every 15 seconds.
> 
> I attach sofia log files (one of 1.12.11 and one of 1.12.10) to this mail. In 
> both
> logs a nua object is created and the ua registers with the german sip provider
> sipgate. After successful registration options keep-alive is started.
> 
> The logs are almost identical until the first answer to an options keep-alive 
> is
> received (around line 140). In sofia 1.12.10 register and options transactions
> are destroyed after timer k has been fired. In sofia 1.12.11 this is missing 
> and
> the options packet is almost immediately resent.
> 
> Is this a known bug or has anyone else seen this behaviour?

Can you check with the latest build off the trunk?
Also please check with a more realistic keep-alive period, 15 seconds is a bit 
extreme anyway...

Best regards,
  Mikhail
--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] test_sip_events.c:338: test_nua test_events() FAILED

[mikhail.zabaluev]

Hi,

> -Original Message-
> From: ext Yungwei Chen [mailto:yung...@resolvity.com]
> Sent: Friday, April 15, 2011 7:58 PM
> To: sofia-sip-devel@lists.sourceforge.net
> Subject: [Sofia-sip-devel] test_sip_events.c:338: test_nua
> test_events() FAILED
> 
> I am trying to compile sofia-sip-1.12.10 on CentOS 5.5, and "make
> check" shows the following. How can I fix it? Thanks.
> 
> TEST NUA-12.5: un-SUBSCRIBE
> test_sip_events.c:338: test_nua test_events() FAILED: tl_find(e->data-
> >e_tags, nutag_substate)->t_value != nua_substate_terminated or 2 != 3

I have a similar problem popping up in a different test (test_simple) off a 
slightly modified master tip.
I suspect there is a race condition there somewhere.
There is certainly a problem in s2check based tests, where the "time warp" hook 
is not used with regard to thread scheduling, but this is a different part of 
the test suite.

Best regards,
  Mikhail
--
Benefiting from Server Virtualization: Beyond Initial Workload 
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve 
application availability and disaster protection. Learn more about boosting 
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Multi home and sofia-sip

[mikhail.zabaluev]

Hi,

> -Original Message-
> From: ext Inca Rose [mailto:incar...@gmail.com]
> Sent: Friday, January 21, 2011 3:50 PM
> To: Pekka Pessi
> Cc: sofia-sip-devel@lists.sourceforge.net
> Subject: Re: [Sofia-sip-devel] Multi home and sofia-sip
> 
> Also there is no way to check from which NIC the proxy is reachable,
> imagine a VPN situation where the proxy is only
> reachable from the VPN but not from the real NIC.

This is not fully solvable on Linux, I believe. You can read the routing table, 
but it can change between the moment you read it and the moment you try to send 
a message.
I think a practical approach is to see which interface has the default gateway 
route, and treat it as the source interface for purposes of Via/Contact/etc. 
This will cover the majority of UA cases with VPN and otherwise. The change 
detection is still needed, though, at least after transport timeouts or 
transactions timing out with no responses.

In fact, the IP binding announced in headers should not matter for modern day 
proxies, as long as they use symmetric response routing as indicated by the UA, 
and the UA updates the registration contact based on the reflected address. 
Unfortunately, in some cases the proxies are too picky.

-- 
  Mikhail
--
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
February 28th, so secure your free ArcSight Logger TODAY! 
http://p.sf.net/sfu/arcsight-sfd2d
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Is CLRF UDP keepalive supported in sofia sip

[mikhail.zabaluev]

Hi,

> -Original Message-
> From: ext Pekka Pessi [mailto:ppe...@gmail.com]
> Sent: Tuesday, January 11, 2011 12:07 AM
> To: nauman762-h...@yahoo.co.uk
> Cc: sofia-sip-devel@lists.sourceforge.net
> Subject: Re: [Sofia-sip-devel] Is CLRF UDP keepalive supported in sofia
> sip
> 
> 2011/1/10 Nauman Sulaiman :
> > Hi, have noticed there is a TCP CLRF keepalive. Was wondering if
> there is equivalent UDP?
> 
> There is no easy keepalive for UDP. In principle, you can use STUN or
> some simple SIP message.

Now that STUN keepalives have been undrafted as part of RFC 5626, should we 
resurrect STUN support in the UDP transport? To be enabled, this will need a 
confirmation from the UAS in the form of "Requires: outbound", so perhaps the 
degree of support in the field should be clarified.

Best regards,
  Misha

--
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

Re: [Sofia-sip-devel] Using VPN

[mikhail.zabaluev]

Hi,

> -Original Message-
> From: ext Nauman Sulaiman [mailto:nauman762-h...@yahoo.co.uk]
> Sent: Tuesday, September 14, 2010 2:28 PM
> To: sofia-sip-devel@lists.sourceforge.net
> Subject: [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.

It should work if the nua stack is created with this tag.
I set it as an url_t equivalent to "sip:IPADDR:*".

That said, it is unfortunate that Sofia cannot determine the preferred IP 
binding by itself, even though it requires platform-specific code (so a Linux 
fix using rtnetlink will not solve the problem for iPhone).

Hope this helps,
  Mikhail
--
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

Re: [Sofia-sip-devel] Invite with XML >>>bad session description

[mikhail.zabaluev]

Hi,

> -Original Message-
> From: ext peter hanshon [mailto:mido.1...@hotmail.fr]
> Sent: Thursday, August 12, 2010 7:38 PM
> To: Zabaluev Mikhail (Nokia-MS/Helsinki); sofia-sip-
> de...@lists.sourceforge.net
> Subject: RE: [Sofia-sip-devel] Invite with XML >>>bad session
> description
> 
> I use :
> 
> 
> nua_handle_t *handl;
>  handl = nua_handle(nua, NULL,
> SIPTAG_TO_STR("sip:192.168.200.236:5060"), TAG_END());
>   nua_invite(handl,SIPTAG_CONTENT_TYPE_STR("application/xml")
>,  SIPTAG_PAYLOAD_STR("bl"),
>TAG_END ());

Why?

-- 
  Mikhail
--
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] sofia-sip not sending correct Via headers in 200 OK to NOTIFY request

[mikhail.zabaluev]

Hi,

> -Original Message-
> From: ext Gaurav Srivastva [mailto:gaurav...@yahoo.com]
> Sent: Monday, August 09, 2010 5:11 AM
> To: sofia-sip-devel@lists.sourceforge.net
> Subject: Re: [Sofia-sip-devel] sofia-sip not sending correct Via
> headers in 200 OK to NOTIFY request
> 
> Looks like my code works fine in linux but is causing problem in OS/X.
> 
> Can someone confirm this issue in OS/X?

I have seen something like this on a Linux before.
The problem seemed to be with parsing a Via header that contains multiple 
entries.

Regards,
  Mikhail

> On Aug 8, 2010, at 2:49 AM, Gaurav Srivastva wrote:
> 
> 
>   Hi,
> 
>   The notify request to the subscription is being responded to by
> Sofia-Sip stack with one Via header from the SIP request missing.
> 
>   In the NOTIFY, the Via header is,
> 
>  Via: SIP/2.0/UDP ift-
> uca.mitel.com:5060;branch=z9hG4bK693c3fbd3b6fa114ad984c7a522a1964.1,SIP
> /2.0/UDP 172.16.14.209:6015;branch=z9hG4bK86266194643563
> 
> 
>   In the 200 OK response, the Via header being sent is,
> 
>  Via: SIP/2.0/UDP ift-
> uca.mitel.com:5060;branch=z9hG4bK693c3fbd3b6fa114ad984c7a522a1964.1;rec
> eived=172.16.14.209
> 
> 
>   I'm using nua to send the subscribe request.
> 
> handle = nua_handle(appl->nua,
> NULL,
> SIPTAG_FROM(from_header),
> SIPTAG_TO(to_header),
> SIPTAG_ROUTE(route_header),
> SIPTAG_CONTACT(contact_header),
> TAG_END());
> 
> 
> if(handle)
> {
>   nua_subscribe(handle,
> SIPTAG_EXPIRES_STR("3600"),
> SIPTAG_EVENT_STR("presence"),
> SIPTAG_ACCEPT_STR("application/pidf+xml"),
> TAG_END());
> 
> 
> }
> 
>   The platform is OSX and xcode IDE.
> 
>   Can someone tell me what I'm doing wrong or is this a bug in
> sofia-sip stack?
--
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Using TLS with sofia

[mikhail.zabaluev]

Hi,

> -Original Message-
> From: ext Pekka Pessi [mailto:ppe...@gmail.com]
> Sent: Friday, August 06, 2010 5:26 PM
> To: nauman762-h...@yahoo.co.uk
> Cc: sofia-sip-devel@lists.sourceforge.net
> Subject: Re: [Sofia-sip-devel] Using TLS with sofia
> 
> 2010/8/2 Nauman Sulaiman :
> > 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?
> 
> You should have root (cafile.pem) and server certificates ready
> (agent.pem) in a suitable directory ($HOME/.sip/auth by default).

IIRC absence of these files was made non-fatal in a patch. Now it's enough if 
the root CA can be verified by OpenSSL's default verification handler.

I'd look into using sips: URIs for registration headers and NUTAG_URL.

Best regards,
  Mikhail
--
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Is sofia-sip dead?

[mikhail.zabaluev]

Hi,

> -Original Message-
> From: Vehmanen Kai (Nokia-D/Tampere)
> Sent: Monday, June 21, 2010 4:45 PM
> To: dan...@drjweb.com; sofia-sip-devel@lists.sourceforge.net
> Subject: Re: [Sofia-sip-devel] Is sofia-sip dead?
> 
> Maemo is using some patches on top of 1.12.10 (e.g. see
> http://repository.maemo.org/pool/maemo5.0/free/s/sofia-sip/ ),
> but AFAIK these will find their way to the official tree,
> if not already all there.

I believe all functional patches are (should re-check with the evil in-house 
repository on my laptop), the remaining patches were about reorganizing some 
build files for our once-special needs.

Best regards,
  Mikhail
--
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] Sofia-SIP sorting of SRV records defeats DNS server round-robin SIP traffic distribution

[mikhail.zabaluev]

Hi,

Thanks for your analysis. If anybody is looking into fixing this, you can also 
consider address affinity for dialogs and transactions: a dialog/transaction 
(in practice, a NUA handle representing either of these) should stick to a 
particular IP protocol/address/port tuple (in Sofia, a “secondary transport”) 
for all outbound requests, unless there is some problem with the transport. 
Services implementing load balancing with DNS are unfortunately less likely to 
maintain shared dialog state between the load balanced proxies.
See 
http://sourceforge.net/tracker/?func=detail&aid=2204637&group_id=143636&atid=756079

Best regards,
  Mikhail

From: ext Jim Thomas [mailto:jimthomasembed...@yahoo.com]
Sent: Friday, March 19, 2010 1:15 AM
To: sofia-sip-devel@lists.sourceforge.net
Subject: [Sofia-sip-devel] Sofia-SIP sorting of SRV records defeats DNS server 
round-robin SIP traffic distribution

Hello,

I am using Sofia-SIP 1.12.10 and it works great.  Thank you
for your open source contribution.

I use an ITSP where, until recently, a DNS lookup by Sofia-SIP
would obtain a single SRV record.  Outbound SIP calls work as
expected every time.

The ITSP now wants to distribute the SIP traffic across three
destinations (three cities), so the same DNS lookup by Sofia-SIP
obtains three SRV records.

The DNS server is provisioned to rotate the SRV records
round-robin, so the first choice will alternate among the three
destinations.  I can see in a packet trace that the SRV record
sequence is in fact alternating across DNS lookups.  (These are
the external DNS lookups after the Sofia-SIP DNS cache expires).
The problem is that even though the DNS response presents the
SRV records in varying order, Sofia-SIP always selects the same
particular SRV record, so outbound calls always go to a single
destination and are not distributed.

I reviewed the Sofia-SIP source, and think I see what is
happening.

Sofia-SIP sorts the SRV records on priority, weight, srv_target,
and srv_port:

  sofia-resolv/sres_record.h
/** Service location record (@RFC2782). */
typedef struct sres_srv_record
{
  sres_common_t  srv_record[1];  /**< Common part of DNS records. */
  uint16_t   srv_priority;   /**< Priority */
  uint16_t   srv_weight; /**< Weight */
  uint16_t   srv_port;   /**< Service port on the target host. */
  uint16_t   srv_pad;
  char  *srv_target; /**< Domain name of the target host. */
} sres_srv_record_t;

  sres.c

sres_record_compare(sres_record_t const *aa, sres_record_t const *bb)
{
  
  case sres_type_srv:
{
  sres_srv_record_t const *A = aa->sr_srv, *B = bb->sr_srv;
  D = A->srv_priority - B->srv_priority; if (D) return D;
  /* Record with larger weight first */
  D = B->srv_weight - A->srv_weight; if (D) return D;
  D = strcmp(A->srv_target, B->srv_target); if (D) return D;
  return A->srv_port - B->srv_port;
}
  
}

If the priority and weight are identical for all three SRV records,
as they are with my ITSP, then the alpha sort of the srv_target name
determines the SRV record sort sequence.

The result is that Sofia-SIP loses the SRV record sequence intended
by the round-robin ordering by the DNS server, and the SRV record
selected by Sofia-SIP is always the record that just happens to have
the target name with the lowest alpha sort key.

It seems to me that the correct sort would be by priority and weight
only, and where those are identical for adjacent records, the original
SRV record sequence would be preserved so the first choice intended
by the DNS server round-robin ordering would be used by Sofia-SIP
to determine where to send the SIP for the outbound call.

Thanks.

Jim

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] FYI: Back again

[mikhail.zabaluev]

Hi,

> -Original Message-
> From: ext Pekka Pessi [mailto:ppe...@gmail.com]
> Sent: Friday, March 12, 2010 6:30 PM
> To: sofia-sip-devel@lists.sourceforge.net
> Subject: [Sofia-sip-devel] FYI: Back again
> 
> As you might have noticed I've not spent much time with Sofia SIP
> lately. However, Sofia SIP has not been abandoned completely. From now
> on, I have reserved some time specifically to maintaining Sofia SIP
> and following this mailing list.

\o/

Gitify, please!

Cheers,
  Mikhail
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] SIP request through TCP if size is longer than threshold

[mikhail.zabaluev]

Hi,

You can bind your stack exclusively to UDP, if you use the parameter 
“transport=udp” in the tag NUTAG_M_PARAMS.

Hope this helps,
  Mikhail

From: ext Aleksander Morgado [mailto:sofia-sip-de...@aleksander.es]
Sent: Friday, January 22, 2010 5:26 PM
To: sofia-sip-devel
Subject: Re: [Sofia-sip-devel] SIP request through TCP if size is longer than 
threshold


When a SIP request long enough is created, like with a large payload, Sofia-SIP 
automatically tries to send the request through TCP instead of UDP. I 
understand that if packet size is more than the maximum UDP packet size allowed 
in the physical network it will not be sent.

But can this behavior be disabled so that instead of trying TCP, the UDP 
request creation *fails*?

This max limit for SIP requests is 1300, as found in some comments in sofia-sip 
source:
 * Maximum size of outgoing UDP request.
 *
 * The maximum UDP request size is used to control use of UDP with overtly
 * large messages. The IETF requires that the SIP requests over 1300 bytes
 * are sent over congestion-controlled transport such as TCP. If a SIP
 * message size exceeds the UDP MTU, the TCP is tried instead of UDP. (If
 * the TCP connection is refused, the stack reverts back to UDP).

Anyway, another option instead of automatically sending it from TCP is to tell 
the app that the UDP request cannot be sent, so that the application can handle 
it and split the request in several less-sized UDP packets.

I am thinking in large NOTIFYs for example. So if sofia-sip detects that NOTIFY 
size is greater than 1300 bytes, depending on the configuration of the NTA we 
could either send the packet using TCP as IETF requires, or tell the 
application that size is too big so that it can split the NOTIFY in several 
ones.

How difficult could it be to implement this in sofia-sip?

Cheers,
-Aleksander
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] TCP sockets blocking ?

[mikhail.zabaluev]

Hi,

>-Original Message-
>From: ext Colin Whittaker [mailto:col...@occamnetworks.com]
>Sent: Friday, October 30, 2009 9:14 PM
>To: sofia-sip-devel@lists.sourceforge.net
>Subject: [Sofia-sip-devel] TCP sockets blocking ?
>
>Back between 1.12.5 and 1.12.6, you removed the
>
>if (su_setblocking(socket, 0) < 0)
>   return *return_reason = "su_setblocking", -1;
>
> From tport_type_tcp.c and tport_type_sctp.c in the
>tport_tcp_init_secondary() functions.
>This causes the TCP sockets to be blocking and the connect() to hang
>until a connection is established or it times out.
>
>For us, running single threaded, causes the stack to hang for 180
>seconds if the registrar is configured improperly, then the retry and
>hang again. Basically causing our application to be unresponsive. Worse
>than a crash for since at least with a crash, we can restart.

It was fixed after 1.12.6 (in 2007, my how time flies!).

Hope this helps,
  Mikhail
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] DNS SRV and Authorization

[mikhail.zabaluev]

Hi,

>-Original Message-
>From: ext Carlos S. Antunes [mailto:c...@nowthor.com] 
>Sent: Friday, August 21, 2009 7:20 AM
>To: sofia-sip-devel@lists.sourceforge.net
>Subject: [Sofia-sip-devel] DNS SRV and Authorization
>
>I am currently testing Freeswitch which, as you probably are aware, 
>relies on Sofia-SIP.
>
>To conduct tests, I am using a Callcentric account.
>
>Callcentric uses DNS SRV records as a way to direct traffic to 
>their SIP 
>proxies. A 'srv' 'dig' of '_sip._udp.callcentric.com' returns:
>
>_sip._udp.callcentric.com. 10025 IN SRV 20 7 5080 
>alpha6.callcentric.com.
>_sip._udp.callcentric.com. 10025 IN SRV 20 7 5080 
>alpha7.callcentric.com.
>_sip._udp.callcentric.com. 10025 IN SRV 20 7 5080 
>alpha1.callcentric.com.
>_sip._udp.callcentric.com. 10025 IN SRV 20 7 5080 
>alpha3.callcentric.com.
>
>Based on this information, Sofia-SIP appears to correctly round robin 
>all available IP addresses. There is a situation, however, in 
>which this 
>round robin causes problems: in the middle of authorizations.

Yes, it's a known problem, it was reported for Maemo devices as well.

A fix would need to implement transport affinity for NTA handles (or perhaps, 
even NUA usages), so that a register usage, or a dialog, sticks to one 
secondary transport for as long as it's available.

Best regards,
  Mikhail
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Network interface selection for sending messages

[mikhail.zabaluev]

Hi,

>-Original Message-
>From: ext ggb [mailto:g...@tid.es] 
>Sent: Wednesday, October 14, 2009 7:11 PM
>To: sofia-sip-devel@lists.sourceforge.net
>Subject: [Sofia-sip-devel] Network interface selection for 
>sending messages
>
>I'm having problems with the network interface selection made by 
>sofia-sip when sending messages.   My PC have 2 interfaces and 
>the stack 
>doesn't select the correct interface (I think the correct would be the 
>one the PC routing table points to for the message target).
>
>Somebody is facing the same problem?

Yes.

>Any solution?

None written yet, AFAIK. A patch to make a practical interface selection based 
on the default route would be most welcome.

>I'm using sofia-sip 1.12.10 under Windows Vista.

Then, your change would have to be specific to Windows. So even if, for 
example, we come up with a patch using Linux rtnetlink or something like that, 
it won't immediately help you.

Best regards,
  Mikhail
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Use empty UDP instead of OPTIONS for keep-alive

[mikhail.zabaluev]

Hi,


From: ext Bengt Werstén [mailto:bengt.wers...@enea.com]
Sent: Tuesday, March 24, 2009 12:37 PM
To: sofia-sip-devel@lists.sourceforge.net
Subject: [Sofia-sip-devel] Use empty UDP instead of OPTIONS for keep-alive

Is it possible to change the behavior of NAT keep-alive to send empty or double 
CLRF UDP packets?
Careful, you won't know when and how the NAT binding changes if you only send 
CRLFs. This is discouraged for UDP in the outbound draft, in-band STUN is 
recommended instead:
http://tools.ietf.org/html/draft-ietf-sip-outbound-16#section-3.5.1

Best regards,
  Mikhail

--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com___
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 sofia select the IP for Via and Contact on a multi home device

[mikhail.zabaluev]

Hi,

>-Original Message-
>From: ext Inca Rose [mailto:incar...@gmail.com] 
>Sent: Saturday, April 04, 2009 12:24 AM
>To: sofia-sip-devel Mailing List
>Subject: [Sofia-sip-devel] How sofia select the IP for Via and 
>Contact on a multi home device
>
>I found something very strange the other day.
>There are 2 IP on the device, Sofia sends the message from IP 1 but
>fill the Via and COntact with IP 2.
>The problem is that IP 2 is not connected to anything.
>Why this happens ?

It's a long-standing problem. Basically, the code selecting the contact does 
not make any good guesses which interface the request will go to. It even used 
to confuse between IPv4 and IPv6 addresses! Looking up the default route would 
be a good heuristic. The full solution would be in rewriting the transport code 
to never bind the UDP socket to "any", and try all available per-interface 
bindings starting from the one with the default route. Some resolver affinity 
would also help, I think: send the requests through the interface to where DNS 
responses arrive.

>Where to look for the code to understand what is going on 
>behind the scenes?

It's between tport, nta, and nua outbound, I believe.

Best regards,
  Mikhail

--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] 904 No Matching Challenge

[mikhail.zabaluev]

Hi,

>-Original Message-
>From: ext Jerry Richards [mailto:jer...@tonecommander.com] 
>Sent: Thursday, March 12, 2009 10:57 PM
>To: Zabaluev Mikhail (Nokia-D/Helsinki)
>Cc: sofia-sip-devel@lists.sourceforge.net
>Subject: RE: 904 No Matching Challenge
>
>Could you send me a patch (or point out the code) for what you 
>described
>below?
>
>"When I removed the line that invalidated the cached challenge upon
>authentication failure, ..."

Ehm, it wasn't strictly a patch, I was just experimenting.
I did it against an older tree. There have been code movements in nua recently, 
so I dropped it for a clean update.
I will try to redo it and check when I have more time. Look for a comment like 
"Bad username/password pair" in the nua code. Pekka may know better where the 
line is now.

Best regards,
  Mikhail


--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] 904 No Matching Challenge

[mikhail.zabaluev]

Hi,

>-Original Message-
>From: ext Martin Drasar [mailto:dra...@optimsys.cz] 
>Sent: Monday, March 09, 2009 10:24 AM
>To: sofia-sip-devel
>Subject: Re: [Sofia-sip-devel] 904 No Matching Challenge
>
>Jerry Richards napsal(a):
>> Hello All,
>> 
>> If my MD5 Authentication username is incorrect, I noticed my 
>sofia-sip phone
>> will get a "904 No Matching Challenge" event in response to my
>> nua_authenticate() call.  This only happens AFTER the first
>> nua_authenticate() call (the first one works correctly).
>> 
>> Has anyone encountered a similar issue?
>
>Yup, I did and some others too (for a bit different use cases 
>though)...
>
>I suggest you search the mailing list. Maybe one of these two 
>will help you a bit:
>
>Sofia-sip no matching challenge 904 in event_callback.
>proxy authentication failed when redirecting

I was onto it when investigating some other problem recently.
It's intended to be legitimate, if the proxy keeps challenging a request to 
which the user supplies the same authentication string more than once. The 
purpose is to eliminate endless request loops.
When I removed the line that invalidated the cached challenge upon 
authentication failure, NUA still failed gracefully on a challenge loop 
condition. I should investigate if this is true for all cases.

>
>There maybe others, but these two I know about
>
>Martin
>
>> Here is the scenario:
>> 
>> NUASofia-SIP   Network
>> --  ---  ---
>> nua_register() ===> ===> REGISTER
>>  (w/o Auth)
>><=== nua_r_register  <=== 401 Unauth.
>> (401 Unauthorized)
>> nua_authenticate() ===> ===> REGISTER
>>  (with Auth)
>><=== nua_r_register
>> (401 Unauthorized)
>> nua_authenticate() ===> 
>><=== nua_r_register
>> (904 Operation has
>>  no matching chal-
>>  lenge)
>> ... 30 seconds elapse here ...
>> nua_register() ===> ===> REGISTER
>>  (w/o Auth)
>><=== nua_r_register  <=== 401 Unauth.
>> (401 Unauthorized)
>> nua_authenticate() ===> 
>><=== nua_r_register
>> (904 Operation has
>>  no matching chal-
>>  lenge)

Best regards,
  Mikhail
--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
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 ethernet interface support?

[mikhail.zabaluev]

From: Zabaluev Mikhail (Nokia-D/Helsinki)
Sent: Monday, February 09, 2009 5:14 PM
To: drostow...@airbiquity.com; sofia-sip-devel@lists.sourceforge.net
Subject: Re: [Sofia-sip-devel] Multiple ethernet interface support?

How does Sofia SIP handle multiple Ethernet interface support? I’m having a 
problem where my linux box has eth0=172.16.1.1, and eth1=192.168.15.115. When 
Sofia sends an INVITE out to the destination 192.168.15.13, my expectation was 
that the source IP address should be 192.168.15.115. However, Ethereal captures 
show the source IP address is actually 172.16.1.1. The INVITE is actually being 
sent out eth1 as I have physically unplugged 172.16.1.1. How does Sofia’s SIP 
socket determine to use eth0’s source IP address? It should be using eth1 as 
the source IP address.
The stack has no clue by default. It binds to INADDR_ANY and uses the first 
interface entry for the source address. There is no standardized way to ask the 
system which route will be taken to reach a destination address (not to mention 
this would be inherently racy). We tried out some Linux-specific magic in our 
team, but this is utterly non-portable and may even break between kernel 
releases. We're not at the stage where it works in a Sofia-SIP branch.
To think of it, a simple heuristic would be to look at the routing table and 
see which interface has the default route. This should work in most cases, e.g. 
VPN. Pekka, what do you think?

Best regards,
  Mikhail
--
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com___
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 ethernet interface support?

[mikhail.zabaluev]

Hi,


From: ext Rostowsky, David [mailto:drostow...@airbiquity.com]
Sent: Thursday, February 05, 2009 8:20 PM
To: sofia-sip-devel@lists.sourceforge.net
Subject: [Sofia-sip-devel] Multiple ethernet interface support?

How does Sofia SIP handle multiple Ethernet interface support? I’m having a 
problem where my linux box has eth0=172.16.1.1, and eth1=192.168.15.115. When 
Sofia sends an INVITE out to the destination 192.168.15.13, my expectation was 
that the source IP address should be 192.168.15.115. However, Ethereal captures 
show the source IP address is actually 172.16.1.1. The INVITE is actually being 
sent out eth1 as I have physically unplugged 172.16.1.1. How does Sofia’s SIP 
socket determine to use eth0’s source IP address? It should be using eth1 as 
the source IP address.
The stack has no clue by default. It binds to INADDR_ANY and uses the first 
interface entry for the source address. There is no standardized way to ask the 
system which route will be taken to reach a destination address (not to mention 
this would be inherently racy). We tried out some Linux-specific magic in our 
team, but this is utterly non-portable and may even break between kernel 
releases. We're not at the stage where it works in a Sofia-SIP branch.

One solution is to bind to a specific interface address with NUTAG_URL in the 
NUA stack parameters.

Hope this helps,
  Mikhail
--
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Received garbage?

[mikhail.zabaluev]

Hi,

>-Original Message-
>From: ext Aleksander Morgado [mailto:sofia-sip-de...@aleksander.es]
>Sent: Monday, February 09, 2009 2:53 PM
>To: sofia-sip-devel Mailing List
>Subject: [Sofia-sip-devel] Received garbage?
>
>Which could be the reason to have a log message like this one
>in sofia-sip?
>
>nta_agent: received garbage from udp/88.30.148.92:5060
>
>Is that a malformed SIP message?

The proxy at SIPphone (AKA Gizmo) sends some weird binary probes in-band. This 
message is what I see when it happens.

Mikhail


--
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Thank you for your contributing excellent library

[mikhail.zabaluev]

Hi,


From: ext Gilbert Lee [mailto:gilgil1...@gmail.com]
Sent: Monday, February 09, 2009 4:07 PM
To: Tan Miaoqing
Cc: sofia-sip-devel@lists.sourceforge.net
Subject: Re: [Sofia-sip-devel] Thank you for your contributing excellent library

The only thing I would like to do in my project is to capture "From" and "To" 
displayname(or username) in SIP message.
Sofia SIP library is excellent, but it's a little heavy for me to adopt it into 
my project, and I've made my own code for myself.
You can still use the lower layers such as the SIP parser.

Best regards,
  Mikhail
--
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com___
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 send a re-INVITE

[mikhail.zabaluev]

Hi,




From: ext mingcheng hu [mailto:h...@yuehetone.com] 
Sent: Saturday, December 27, 2008 10:05 AM
To: sofia-sip-devel@lists.sourceforge.net
Subject: [Sofia-sip-devel] How to send a re-INVITE


 I need to send a re-INVITE to update media's state ,but I don't 
know how to send re-INVITE in Sofia SIP. Who can give me some tips or examples.
 

Simple: use nua_invite with the handle you used for the initial nua_invite.
 
Hope this helps,
  Mikhail
 
--
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] [BUG] SIP uri params specified in the TO_TAG_STRwrongly detected as the To header params

[mikhail.zabaluev]

Hi, 

>-Original Message-
>From: ext Stefano Sabatini [mailto:[EMAIL PROTECTED] 
>Sent: Friday, November 21, 2008 12:00 PM
>To: sofia-sip-devel Mailing List
>Subject: [Sofia-sip-devel] [BUG] SIP uri params specified in 
>the TO_TAG_STRwrongly detected as the To header params
>
>On the other hand sofia sip seems to get confused when parsing the
>TO_TAG, and it consider the uri params like header params.
>
>Making this clear with an example:
>
>nua_invite(op->handle,
>   SIPTAG_FROM_STR("Alice "),
>   SIPTAG_TO_STR("sip:[EMAIL PROTECTED];foo=bar"),
>   NUTAG_MEDIA_ENABLE(0),
>   TAG_END());
>
>will issue the following INVITE message:
>
>   INVITE sip:[EMAIL PROTECTED] SIP/2.0
>   Via: SIP/2.0/UDP 10.88.3.67;rport;branch=z9hG4bKmKgXBK495Byyp
>   Max-Forwards: 70
>   From: Alice ;tag=m4KHeHvHZeU8Q
>   To: ;foo=bar
>   Call-ID: 8f686cee-3254-122c-6ebf-001a4b5c8ed5
>   CSeq: 107512154 INVITE
>   Contact: 
>   User-Agent: sofia-sip/1.12.9
>   Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, 
>SUBSCRIBE, NOTIFY, REFER, UPDATE
>   Supported: timer, 100rel
>   Min-SE: 120
>   Content-Length: 0
>
>foo=bar is consiedered as an *header* param, while it was specified as
>an *uri* param.
>
>In order to get the correct behaviour (uri params in the request line)
>I have to specify the sip uri in the To tag like this:
>
>SIPTAG_TO_STR(""), in which case I got:
>
>   INVITE sip:[EMAIL PROTECTED];foo=bar SIP/2.0
>   Via: SIP/2.0/UDP 10.88.3.67;rport;branch=z9hG4bK4S4Be5m0UB9HS
>   Max-Forwards: 70
>   From: Alice ;tag=4tjrS2F4397pp
>   To: 
>   Call-ID: f27c4f9b-3254-122c-0e84-001a4b5c8ed5
>   CSeq: 107512237 INVITE
>   Contact: 
>   User-Agent: sofia-sip/1.12.9
>   Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, 
>SUBSCRIBE, NOTIFY, REFER, UPDATE
>   Supported: timer, 100rel
>   Min-SE: 120
>   Content-Length: 0
>
>I think this is a bug in sofia-sip.

I disagree. SIPTAG_TO_STR accepts the value for the entire To: header, not just 
the URI.
If you want more discretion, form a sip_to_t structure and pass it to 
SIPTAG_TO. 

Best regards,
  Mikhail

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] one small feature request to implement event/state mask

[mikhail.zabaluev]

Hi,





From: ext liu yang [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, October 28, 2008 12:56 PM
To: Zabaluev Mikhail (Nokia-D/Helsinki)
Cc: sofia-sip-devel@lists.sourceforge.net; Pessi Pekka 
(Nokia-D/Helsinki); Rostowsky, David
Subject: [Sofia-sip-devel] one small feature request to implement 
event/state mask


For the "CANCEL" question, I tried "APPL_METHOD" before I writed mail 
to mail list, but failed. I think, stack code change is needed.

OK, file a feature request about this to 
https://sourceforge.net/projects/sofia-sip
 
Best regards,
  Mikhail
 
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Initialize sofia in the main context thread and run it in another thread

[mikhail.zabaluev]

Hi,

>-Original Message-
>From: [EMAIL PROTECTED] 
>[mailto:[EMAIL PROTECTED] On 
>Behalf Of ext Rémi BUISSON
>Sent: Friday, September 12, 2008 9:32 AM
>To: sofia-sip-devel@lists.sourceforge.net
>Subject: Re: [Sofia-sip-devel] Initialize sofia in the main 
>context thread and run it in another thread
>
>DBus works on windows and you can attach both DBus loop and sofia-sip 
>loop to a GMainLoop (glib works on windows to).

An example is Telepathy-SofiaSIP:
http://telepathy.freedesktop.org/wiki/Components

We disable threading in Sofia-SIP, and it works wonderfully in the common main 
loop alongside DBus-Glib.

-- 
  Mikhail

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Messages control

[mikhail.zabaluev]

Hi,




From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ext 
Peter McAfee
Sent: Tuesday, August 26, 2008 3:56 PM
To: sofia-sip-devel@lists.sourceforge.net
Subject: [Sofia-sip-devel] Messages control


is it possible using nua interface to send negative replys to in 
comming  sip MESSAGE  ie instant messages

Sure, just mention "MESSAGE" in the NUTAG_APPL_METHOD to your NUA stack.
You'll have to reply to all incoming messages explicitly, then.
 
Best regards,
  Mikhail
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

[Sofia-sip-devel] Binding issues (was: Can NUA resolve domain names?)

[mikhail.zabaluev]

Hi,




From: ext Diego Costantini [mailto:[EMAIL PROTECTED] 
Sent: Friday, September 05, 2008 6:33 PM
To: Zabaluev Mikhail (Nokia-D/Helsinki)
Cc: sofia-sip-devel@lists.sourceforge.net
Subject: RE: [Sofia-sip-devel] Can NUA resolve domain names?



Now it works but I have another problem.

I am binding sofia to sip:*:5067 and apparently can receive messages 
correctly, but when I try to send one, it uses the first eth it finds, not the 
proper one from route.

E.g.:

[EMAIL PROTECTED]:~/nec/libvoip$ route -e

Kernel IP routing table

Destination Gateway Genmask Flags   MSS Window  
irtt Iface

192.168.100.0   192.168.150.11  255.255.255.0   UG0 0  
0 eth2

10.10.150.0 *   255.255.255.0   U 0 0  
0 eth1

192.168.150.0   *   255.255.255.0   U 0 0  
0 eth2

10.0.2.0*   255.255.255.0   U 0 0  
0 eth0

link-local  *   255.255.0.0 U 0 0  
0 eth1

default 10.0.2.20.0.0.0 UG0 0  
0 eth0

default 192.168.150.11  0.0.0.0 UG0 0  
0 eth2

 

when I send to 10.10.150.101, the source is 10.0.2.15, so the message 
is lost.

The correct outgoing interface should be 10.10.150.100

 

Am I missing a sofia tag to use the correct souce IP for every message, 
or it is not supported (or a bug)?

To use a non-default route, you have to bind the stack to the IP address of the 
interface you want to use.

I filed a bug 

  about it.

 

Hope this helps,

  Mikhail

 

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Can NUA resolve domain names?

[mikhail.zabaluev]

Hi,




From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ext 
Diego Costantini
Sent: Friday, September 05, 2008 12:32 PM
To: sofia-sip-devel@lists.sourceforge.net
Subject: [Sofia-sip-devel] Can NUA resolve domain names?



In a previous thread with different topic I mentioned this problem, but 
now I try to make it more clear:

 

handle = nua_handle(nua, NULL, SIPTAG_TO_STR(to), TAG_END());

 

or

 

  nua_message(handle,

SIPTAG_TO_STR(to),

SIPTAG_FROM_STR(from),

...

 

With to = sip:[EMAIL PROTECTED]:5068 doesn't work, with to = sip:[EMAIL 
PROTECTED]:5068 it works.

 

Any hint? 

 

Is japan.lan really resolvable in your DNS configuration? Sofia-SIP doesn't use 
the system resolver, so /etc/hosts and such do not work. 

 

Best regards,

  Mikhail

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Simple NTA processing...

[mikhail.zabaluev]

Hi,

>-Original Message-
>From: [EMAIL PROTECTED] 
>[mailto:[EMAIL PROTECTED] On 
>Behalf Of ext Stuart Whelan
>Sent: Wednesday, September 03, 2008 1:09 AM
>To: sofia-sip-devel@lists.sourceforge.net
>Subject: Re: [Sofia-sip-devel] Simple NTA processing...
>
>Solved the problem...
>
>I should of course be returning 200, not SIP_200_OK.

Mmm, scary syntax-intrusive macros, meeting the lack of type checks...

BR,
  Mikhail

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
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 free a sdp_session_t struct

[mikhail.zabaluev]

Hi

>-Original Message-
>From: [EMAIL PROTECTED] 
>[mailto:[EMAIL PROTECTED] On 
>Behalf Of ext Stefano Sabatini
>Sent: Monday, September 01, 2008 6:56 PM
>To: sofia-sip-devel@lists.sourceforge.net
>Subject: Re: [Sofia-sip-devel] How to free a sdp_session_t struct
>
>So if I understood it correctly I need to keep an home just for every
>sdp_session_t.

Well, you can use one home for multiple objects.

-- 
  Mikhail

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
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 free a sdp_session_t struct

[mikhail.zabaluev]

Hi, 

>-Original Message-
>From: [EMAIL PROTECTED] 
>[mailto:[EMAIL PROTECTED] On 
>Behalf Of ext Stefano Sabatini
>Sent: Monday, September 01, 2008 3:44 PM
>To: sofia-sip-devel@lists.sourceforge.net
>Subject: Re: [Sofia-sip-devel] How to free a sdp_session_t struct
>
 Free the home used for allocating the session.
>>>
>>> Hi, and thanks for the reply.
>>> Yes that's a solution, nonetheless it looks still weird to 
>me, to have
>>> to use an home just for that seems
>>> overkill.
>>
>> There is also this problem. Assuming that I have to pass around the
>> allocated home, I can't use a stack allocated home, so I
>> have to use su_home_new() (here choosing an arbitrary size value...).
>>
>> Then I think there is no way to know the home used by an 
>sdp_session_t
>> object, so I would have to pass around the home
>> object to which the sdp_session_t is bound, which is pretty awkward,
>> *either* to have a memleak.
>
>Another solution could be to pass around sdp_parser_t rather than
>sdp_session_t, then
>use sdp_session() to get the sdp_session_t from the parser and free
>both parser and
>session with sdp_parser_free(), do you think this is an 
>acceptable solution?
>
>But still this looks like a strange solution and not particularly
>convenient (why to pass around the whole parser if what I need is just
>the session?), and is the reason for which I was looking for an
>sdp_session_free() function.

I guess you don't really want to keep the parser state.
A home is a pool for allocated memory in the Sofia stack, so yes, you need to 
pass it around to wherever you free the sdp_session_t.

Kind regards,
  Mikhail

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
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 free a sdp_session_t struct

[mikhail.zabaluev]

Hi,

>-Original Message-
>From: [EMAIL PROTECTED] 
>[mailto:[EMAIL PROTECTED] On 
>Behalf Of ext Stefano Sabatini
>Sent: Friday, August 29, 2008 6:24 PM
>To: sofia-sip-devel@lists.sourceforge.net
>Subject: [Sofia-sip-devel] How to free a sdp_session_t struct
>
>Hi all sofia-sippers,
>
>I'm looking for the best method to free an sdp_session_t struct.
>
>I see there is an sdp_session_dup() function, and there are
>sdp_printer_free() and sdp_parser_free(), so I was expecting some
>method such as sdp_session_free().
>
>Missing that, then I wonder if its absence means something, for
>example that there is some convenient method to free an sdp_session_t.
>
>Can you give some hint?

Free the home used for allocating the session.

Best regards,
  Mikhail

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] TEL URI

[mikhail.zabaluev]

Hi,

>-Original Message-
>From: ext Jerry Richards [mailto:[EMAIL PROTECTED] 
>Sent: Wednesday, July 23, 2008 5:33 PM
>To: Zabaluev Mikhail (Nokia-D/Helsinki); 
>sofia-sip-devel@lists.sourceforge.net
>Subject: RE: [Sofia-sip-devel] TEL URI
>
>Thanks for your reply.  Yes I am sending the TAG_END(), I just 
>forgot to
>paste it into the Email.  Do you see anything I'm doing wrong?

Sorry, it's hard to tell from a snippet that's not even real code (I didn't 
notice at first glance).

>Also, the sofia-sip-conformance.html page includes the 
>following note with
>respect to tel URIs:  Missing: Resolving the tel: URIs.
>
>Do you know what this note means? 

I guess it means not doing ENUM lookups on the client side.

Best regards,
  Mikhail

>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
>Sent: Wednesday, July 23, 2008 4:10 AM
>To: [EMAIL PROTECTED]; sofia-sip-devel@lists.sourceforge.net
>Subject: RE: [Sofia-sip-devel] TEL URI
>
>Hi, 
>
>>-Original Message-
>>From: [EMAIL PROTECTED]
>>[mailto:[EMAIL PROTECTED] On 
>Behalf Of ext 
>>Jerry Richards
>>Sent: Wednesday, July 23, 2008 1:42 AM
>>To: sofia-sip-devel@lists.sourceforge.net
>>Subject: [Sofia-sip-devel] TEL URI
>>
>>I am trying to send an INVITE using a tel URI instead of a SIP URI.
>>According to the following page, sofia-sip should support this:
>>
>>http://sofia-sip.sourceforge.net/refdocs/sofia_sip_conformance.html
>>
>>However, the following API calls result in a 900 Internal NUA Error at
>>../../../libsofia-sip-ua/nua/nua_stack.c:2445 (number might differ 
>>v1.12.7), and no SIP message is sent:
>>
>>nua_handle(nua, hmagic,
>> 
>>NUTAG_URL(tel:8000;phone-context=greyhawk.tonecommander.com.;us
>>er=phone;tran
>>sport=udp),
>>SIPTAG_SUPPORTED(timer, 100rel, resource-priority, preconditions) 
>>); nua_invite(nh, NUTAG_M_USERNAME(10282),
>>SIPTAG_FROM("" ),
>> 
>>SIPTAG_TO(tel:8000;phone-context=greyhawk.tonecommander.com.;us
>>er=phone;tran
>>sport=udp),
>>SIPTAG_P_PREFERRED_IDENTITY(sip:[EMAIL PROTECTED])
>>);
>>
>>Does anyone know why this is not accepted?

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] TEL URI

[mikhail.zabaluev]

Hi, 

>-Original Message-
>From: [EMAIL PROTECTED] 
>[mailto:[EMAIL PROTECTED] On 
>Behalf Of ext Jerry Richards
>Sent: Wednesday, July 23, 2008 1:42 AM
>To: sofia-sip-devel@lists.sourceforge.net
>Subject: [Sofia-sip-devel] TEL URI
>
>I am trying to send an INVITE using a tel URI instead of a SIP URI.
>According to the following page, sofia-sip should support this:
>
>http://sofia-sip.sourceforge.net/refdocs/sofia_sip_conformance.html
>
>However, the following API calls result in a 900 Internal NUA Error at
>../../../libsofia-sip-ua/nua/nua_stack.c:2445 (number might 
>differ v1.12.7),
>and no SIP message is sent:
>
>nua_handle(nua, hmagic,
> 
>NUTAG_URL(tel:8000;phone-context=greyhawk.tonecommander.com.;us
>er=phone;tran
>sport=udp),
>SIPTAG_SUPPORTED(timer, 100rel, resource-priority, preconditions)
>);
>nua_invite(nh, NUTAG_M_USERNAME(10282),
>SIPTAG_FROM("" ),
> 
>SIPTAG_TO(tel:8000;phone-context=greyhawk.tonecommander.com.;us
>er=phone;tran
>sport=udp),
>SIPTAG_P_PREFERRED_IDENTITY(sip:[EMAIL PROTECTED])
>);
>
>Does anyone know why this is not accepted?

Could it just be missing TAG_END() at the end of the tag list?

Best regards,
  Mikhail

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Sofia-SIP conceptual model with regard to hmagic

[mikhail.zabaluev]

Hi, 

>-Original Message-
>From: [EMAIL PROTECTED] 
>[mailto:[EMAIL PROTECTED] On 
>Behalf Of ext Jim Thomas
>Sent: Wednesday, July 02, 2008 4:58 PM
>To: sofia-sip-devel@lists.sourceforge.net
>Subject: [Sofia-sip-devel] Sofia-SIP conceptual model with 
>regard to hmagic
>
>I am experimenting with Sofia-SIP and like it very much.
>I am currently carrying a 'call' structure around via the 
>nua_hmagic_t hmagic pointer.  It works well.
>However, it looks like this same hmagic pointer may also be 
>used in some non-call situations such as registration.
>In anticipation of a C++ object model, I am trying to think 
>about what to name a base class to be conveyed via the hmagic 
>pointer, where derived classes will have names suitable to 
>their specialization.
>I suspect one derived class will be 'Call', but I don't know 
>enough yet about Sofia SIP to anticipate proper terminology 
>for the base class and other derived classes alongside Call.
>Any suggestions?  I would like to name these things in a way 
>that aligns well with the Sofia-SIP conceptual model and any 
>existing naming conventions.

In the Telepathy-SofiaSIP trunk refactored a few months ago, I use a "NUA event 
target" base class which encapsulates a NUA handle and converts callback events 
for that handle into GObject signal emissions. The classes for call, 
registration maintenance, etc. inherit from that base class and handle some of 
the signals. A close approach in C++ could be to have the base class convert 
events into virtual method calls, or use a C++ signal/slot framework.

HTH,
  Mikhail

-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Setting NUTAG_PROXY()

[mikhail.zabaluev]

 

>-Original Message-
>From: ext Jerry Richards [mailto:[EMAIL PROTECTED] 
>Sent: Wednesday, July 02, 2008 5:33 PM
>To: Zabaluev Mikhail (Nokia-D/Helsinki); 
>sofia-sip-devel@lists.sourceforge.net
>Subject: RE: [Sofia-sip-devel] Setting NUTAG_PROXY()
>
>Okay.  Since the user may specify a URL that doesn't begin 
>with "sip:", I
>implemented it in the following way and it works:
>
>// proxy is hard-coded here as an example
>char proxy[URI_LENGTH] = 
>{"jerryr-xppro.greyhawk.tonecommander.com");
>url_t *obUrl = url_format(appl->home, "%s", proxy);

Simplified that for you:

url_t *obUrl = url_make(appl->home, proxy);

Still, if the user is able to enter "host:5060", you're back to the original 
problem, so better check the input string for colons.

HTH,
  Mikhail


>Try "sip:jerryr-xppro.greyhawk.tonecommander.com:5060". The 
>tag expects an
>URI.
>
>Best regards,
>  Mikhail
>
>>-Original Message-
>>From: Jerry Richards [mailto:[EMAIL PROTECTED]
>>Sent: Monday, June 30, 2008 12:21 PM
>>To: 'sofia-sip-devel@lists.sourceforge.net'
>>Subject: Setting NUTAG_PROXY()
>>
>>Hello All,
>>
>>Why does the sofia-sip stack reply with event "900 Error setting NTA 
>>parameters" when I specify a port # in the NUTAG_PROXY() parameter 
>>string, as shown below:
>>
>>Url_string_t outbound_proxy;
>>strcpy(outbound_proxy, 
>"jerryr-xppro.greyhawk.tonecommander.com:5060");
>>nua_set_params(nua, NUTAG_PROXY(&outbound_proxy), TAG_END());
>>
>>If I remove the ":5060" on the end, then it does not get an error.

-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Setting NUTAG_PROXY()

[mikhail.zabaluev]

Hi,

>-Original Message-
>From: [EMAIL PROTECTED] 
>[mailto:[EMAIL PROTECTED] On 
>Behalf Of ext Jerry Richards
>Sent: Monday, June 30, 2008 10:28 PM
>To: sofia-sip-devel@lists.sourceforge.net
>Subject: Re: [Sofia-sip-devel] Setting NUTAG_PROXY()
>
>By the way, in my original Email, the following line is a correction:
>
>strcpy(outbound_proxy.us_str,
>"jerryr-xppro.greyhawk.tonecommander.com:5060");

Try "sip:jerryr-xppro.greyhawk.tonecommander.com:5060". The tag expects an URI.

Best regards,
  Mikhail

>-Original Message-
>From: Jerry Richards [mailto:[EMAIL PROTECTED] 
>Sent: Monday, June 30, 2008 12:21 PM
>To: 'sofia-sip-devel@lists.sourceforge.net'
>Subject: Setting NUTAG_PROXY()
>
>Hello All,
>
>Why does the sofia-sip stack reply with event "900 Error setting NTA
>parameters" when I specify a port # in the NUTAG_PROXY() 
>parameter string,
>as shown below:
>
>Url_string_t outbound_proxy;
>strcpy(outbound_proxy, "jerryr-xppro.greyhawk.tonecommander.com:5060");
>nua_set_params(nua, NUTAG_PROXY(&outbound_proxy), TAG_END());
>
>If I remove the ":5060" on the end, then it does not get an error.
>
>Anyone know why?

-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Ignoring Duplicate SDP

[mikhail.zabaluev]

Hi,

>-Original Message-
>From: [EMAIL PROTECTED] 
>[mailto:[EMAIL PROTECTED] On 
>Behalf Of ext Bernhard Suttner
>Sent: Wednesday, June 04, 2008 5:54 PM
>To: Pekka Pessi
>Cc: [EMAIL PROTECTED]
>Subject: Re: [Sofia-sip-devel] Ignoring Duplicate SDP
>
>Hi,
>
>thanks for your fast answer.
>
>> You could hack nua_session.c not to ignore SDP, but compare it with
>> previous one, and if they differ, generate new offer (and ignore it)
>> and then feed new sdp as an answer to it.
>
>ok. I have another "hack":
>
>  else if (!session_get_description(sip, &sdp, &len))
>/* No SDP */;
>  //else if (cr->cr_answer_recv) {
>/* Ignore spurious answers after completing O/A */
>//LOG3("ignoring duplicate");
>//sdp = NULL;
>  //}
>  else if (cr->cr_offer_sent) {
>
>(just commented the code). 
>
>Do you think that this can break something?
>
>Will there by a _complete_ implemenation of such scenarios because I
>think there are many use-cases like this? Just think about, that a PBX
>has also a media server (same IP but different port) and will play a
>cool ringback tone in Session Progress and later it want to connect the
>user according to the 200 OK SDP.

And mixing the ringback tone into the stream that's ultimately going to carry 
voice is not an option?
Remember, each network address change brings a potential NAT traversal process, 
with associated potential for breakage.
So far I haven't seen any PBX changing the SDP between early and complete 
phases. Also, as Pekka has mentioned, it hits some really weird SOA-in-SIP 
scenarios; I'm not sure it's even allowed by the specs.

Best regards,
  Mikhail

-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] question about writing a sip client with videocapability

[mikhail.zabaluev]

Hi,




From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ext mark 
morreny
Sent: Wednesday, May 14, 2008 5:22 AM
To: sofia-sip-devel@lists.sourceforge.net
Subject: [Sofia-sip-devel] question about writing a sip client with 
videocapability


Hi,
I am looking for a sip client that can display streaming video during a 
multi-party conference session.  I have done some research on Goggle and the 
only one I can find is xLite but it does not have the multiple video output 
that I am looking for.   As a result of that, I am struggling with the idea of 
writing my own sip client that can serve the specific purpose I need.  Instead 
of writing everything from groun zero, could someone  suggest any open source 
toolkit that I can use to develop the multi-party video conferencing feature I 
am looking for?

Farsight 2 is work in progress:
http://farsight.freedesktop.org/
 
There's also an umbrella project that gathers Sofia-SIP and Farsight under one 
framework:
http://telepathy.freedesktop.org/
 
Hope this helps,
  Mikhail, a developer of Telepathy-SofiaSIP
 
-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/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] Directionailty bid-down in SOA (Was: sofia-sip changes (2008-05-12))

[mikhail.zabaluev]

Hi,

While you're at it, I've noticed that the SOA module does not allow the user 
SDP answer to bid down stream directions.
AFAIK, it's perfectly valid to answer with a=sendonly, a=recvonly, or 
a=inactive if the offer had the stream bidirectional.
In Sofia-SIP 1.12.8, direction specified by user SDP is ignored when forming 
the answer.

Best regards,
  Mikhail

>-Original Message-
>From: [EMAIL PROTECTED] 
>[mailto:[EMAIL PROTECTED] On 
>Behalf Of ext Sofia-SIP Darcs Changes
>Sent: Monday, May 12, 2008 9:56 PM
>To: sofia-sip-devel@lists.sourceforge.net
>Subject: [Sofia-sip-devel] sofia-sip changes (2008-05-12)
>
>This posting was generated automatically from darcs repo
>.
>
>Mon May 12 21:33:37 EEST 2008  [EMAIL PROTECTED]
>  * soa_static.c: cope better if m= lines gets removed from user sdp
>
>M ./libsofia-sip-ua/soa/soa_static.c -9 +17
>M ./libsofia-sip-ua/soa/test_soa.c -2 +154
>
>Mon May 12 20:47:33 EEST 2008  [EMAIL PROTECTED]
>  * soa_static.c: mark m= line rejected if its user sdp line is removed
>
>M ./libsofia-sip-ua/soa/soa_static.c -1 +6

-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] INVITE source IP address

[mikhail.zabaluev]

Hi,
 
I want similar information, the destination IP address for the outgoing 
"secondary" transport used by a NUA handle.
AFAIK there's no way to retrieve peer's IP address, could a tag be made for 
that?

-- 
  Mikhail



From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ext Matt 
Krokosz
Sent: Friday, April 25, 2008 6:53 PM
To: sofia-sip-devel@lists.sourceforge.net
Subject: [Sofia-sip-devel] INVITE source IP address



Using the nua module, when an INVITE is received, is there anyway to 
determine the source IP address from the transport layer, rather then from the 
SIP msg headers such as Contact or From?

 

Matt

-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Missing NUA callbacks with su_glib

[mikhail.zabaluev]

Hi, 

>-Original Message-
>From: [EMAIL PROTECTED] 
>[mailto:[EMAIL PROTECTED] On 
>Behalf Of ext Alexander Beisig
>Sent: Monday, April 21, 2008 8:24 PM
>To: sofia-sip-devel@lists.sourceforge.net
>Subject: [Sofia-sip-devel] Missing NUA callbacks with su_glib
>
>When I compile this program against sofia-sip 1.12.8, run it and call 
>the machine running it with a SIP phone, I don't get any "callback" 
>output.  If I uncomment the line that starts the timer, I get both 
>"timeout" and "callback" messages when doing the same test.  I 
>think the 
>NUA callback function should be called regardless of the timer.  Am I 
>missing something?

The code does not create any requests that would produce (non-bogus) NUA events.
Try nua_register() or something.

Best regards,
  Mikhail

-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] nua_handle_destroy

[mikhail.zabaluev]

Hi,

>-Original Message-
>From: [EMAIL PROTECTED] 
>[mailto:[EMAIL PROTECTED] On 
>Behalf Of ext Pekka Pessi
>Sent: Tuesday, March 11, 2008 1:57 PM
>To: Bernhard Suttner
>Cc: sofia-sip-devel@lists.sourceforge.net
>Subject: Re: [Sofia-sip-devel] nua_handle_destroy
>
>2008/3/11, Bernhard Suttner <[EMAIL PROTECTED]>:
>>  has nobody any suggestion? I would be very pleased if someone has a
>>  idea.
>
>You keep handle if you have use for it in the future, you destroy it
>if you don't. If you serve PUBLISH or REGISTER or MESSAGE, there is no
>state associated with the handle and you should destroy it. With
>incoming INVITE, if you accept it by responding with 200, Sofia
>creates session state, and you should keep the handle until the
>session is terminated.

I code to the idea that it's better to unref handles and let the stack decide 
what to do with them.
NB: Handles left to linger until the stack shutdown are a common occurrence in 
some unusual cases; to make matters worse, they delay a proper shutdown until 
after a shutdown timeout is expired.

Best regards,
  Mikhail

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Transport Controls

[mikhail.zabaluev]

Hi, 

>-Original Message-
>From: [EMAIL PROTECTED] 
>[mailto:[EMAIL PROTECTED] On 
>Behalf Of ext Jerry Richards
>Sent: Friday, March 07, 2008 8:26 PM
>To: sofia-sip-devel@lists.sourceforge.net
>Subject: [Sofia-sip-devel] Transport Controls
>
>Hello All,
>
>Firstly, my application needs to specify the transport as UDP 
>or TCP (and
>eventually TLS).  The default transport appears to be UDP.  
>How can I force
>the transport to be TCP?  I saw earlier mailings about setting
>"transport=xxx" in the Contact header.  However, up until now 
>I have let the
>stack generate the Contact header, because I have one user agent and
>multiple registrations that go by unique AORs.  I hope I don't 
>have to add a
>SIPTAG_CONTACT_STR() tag to every API call.

Use NUTAG_URL, e.g. NUTAG_URL("sip:*:*;transport=tcp")

We used to do it in NUTAG_M_PARAMS, but it doesn't quite do the job.

Best regards,
  Mikhail

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] about sophia-sip and gstreamer

[mikhail.zabaluev]

Hi,




From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ext 
souilem fadi
Sent: Tuesday, March 04, 2008 1:11 PM
To: sofia-sip-devel@lists.sourceforge.net
Subject: [Sofia-sip-devel] about sophia-sip and gstreamer


hello everybody  : 
I 'm a student performing his graduation project , it consist of  
designing a videoconferencing application  which uses sophia-sip as a sip stack 
and gstreamer as a media stack , so i'm wondering if this is possible ? 
specially that sophia-sip was designed maily for nokia , and as i know  nokia 
isn't using gstreamer for media handeling .

I must say your knowledge is incomplete :)
 
http://rtcomm.garage.maemo.org/
http://telepathy.freedesktop.org/wiki/
http://farsight.freedesktop.org/wiki/
 
Best regards,
  Mikhail
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] sofia-sip changes (2008-02-12)

[mikhail.zabaluev]

Hi, 

>-Original Message-
>From: [EMAIL PROTECTED] 
>[mailto:[EMAIL PROTECTED] On 
>Behalf Of ext Sofia-SIP Darcs Changes
>Sent: Tuesday, February 12, 2008 9:56 PM
>To: sofia-sip-devel@lists.sourceforge.net
>Subject: [Sofia-sip-devel] sofia-sip changes (2008-02-12)
>
>This posting was generated automatically from darcs repo
>.
>
>Tue Feb 12 21:26:26 EET 2008  [EMAIL PROTECTED]
>  * tport.c: tport_name_dup() now validates the input
>
>M ./libsofia-sip-ua/tport/tport.c +3

So, a null tpn_port field is not allowed?
Any idea on what might cause it to be NULL in that crash?

Best regards,
  Mikhail

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
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 compile sofsip without glib

[mikhail.zabaluev]

Hi, 

>-Original Message-
>From: ext jason_jiang in amit [mailto:[EMAIL PROTECTED] 
>Sent: Tuesday, January 15, 2008 1:45 PM
>To: Zabaluev Mikhail (Nokia-D/Helsinki)
>Cc: sofia-sip-devel@lists.sourceforge.net
>Subject: Re: [Sofia-sip-devel] how to compile sofsip without glib
>
>Thank for your explaination, really preciated.  Do you have 
>experiences on delevlop sip-phone on cross-platform to share 
>with me. If 
>I wanna put sofsip onto a target with arm cpu, do I try to 
>compile glib 
>using cross-compiler, then compile sofsip with glibc, and finally put  
>sofia-sip.so and  libglib.so and sofsip onto my target to run.  Sorry, 
>I'm new to sip's world, hope some advanced can give me helps. 
>thank you 
>a lot.

Yes, that's the basic scheme, unless you already have glib in your 
cross-compilation environment and on the target.
We use Scratchbox for cross-building:
http://scratchbox.org/

Best regards,
  Mikhail

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Any deb package of sofia-sip for maemo?

[mikhail.zabaluev]

Hi,
 
Sorry for taking too long to respond, the problem was we didn't have a proper 
source package repository for IT OS 2008 up until recently.
Now we do:
http://lists.maemo.org/pipermail/maemo-developers/2008-January/013669.html
 
You can find the source package for sofia-sip there:
http://repository.maemo.org/pool/os2008/free/source/s/sofia-sip/
 
Hope this helps,
  Mikhail




From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ext Tan 
Miaoqing
Sent: Wednesday, November 21, 2007 1:53 PM
To: sofia-sip-devel@lists.sourceforge.net
Subject: [Sofia-sip-devel] Any deb package of sofia-sip for maemo?


Dear all,

Is there any deb package of sofia-sip for maemo? 

I have found this link:

http://jonek.hexbox.de/?p=43

It works pretty well, including a maemo version of sofsip_cli. However, 
the version of sofia-sip in this repository is too low. Thus, I would like to 
ask if sofia-sip developers have made any deb package for maemo? 

Of course, I also notice this one:

http://rtcomm.garage.maemo.org/

But I would prefer a separate sofia-sip package, and it would be great 
if it supports maemo 2.x, as currently I have only 770 around...

-- 
Best Regards
Tan Miaoqing
Master's Programme in Mobile Computing - Services and Security
Helsinki University of Technology
http://users.tkk.fi/~mitan 

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
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 compile sofsip without glib

[mikhail.zabaluev]

Hi, 

>-Original Message-
>From: [EMAIL PROTECTED] 
>[mailto:[EMAIL PROTECTED] On 
>Behalf Of ext jason_jiang in amit
>Sent: Tuesday, January 15, 2008 12:38 PM
>To: sofia-sip-devel@lists.sourceforge.net
>Subject: [Sofia-sip-devel] how to compile sofsip without glib
>
>  I have had a question for a long time. Why does sofsip have to work 
>with glib?Are there  methods to compile softsip without glib, 
>because I 
>just wanna it run in the text mode only.

Glib != GTK.
It's just a cross-platform utility library, without any windowing functionality.

Best regards,
  Mikhail

-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Assertion `sub && sub->sub_ref != 0' failed

[mikhail.zabaluev]

Hi, 

>-Original Message-
>From: ext Fabio Margarido [mailto:[EMAIL PROTECTED] 
>Sent: Wednesday, December 19, 2007 12:25 PM
>To: Zabaluev Mikhail (Nokia-M/Helsinki)
>Cc: sofia-sip-devel@lists.sourceforge.net
>Subject: Re: [Sofia-sip-devel] Assertion `sub && sub->sub_ref 
>!= 0' failed
>
>On Dec 19, 2007 7:38 AM,  <[EMAIL PROTECTED]> wrote:
>> Do you explicitly destroy any handles rather than unreffing them?
>> I remember I had some problem with posthumous event delivery 
>in a corner case,
>> or something.
>
>Yes, I do. From what I understood from the documentation, this
>shouldn't be a problem. Should I call nua_handle_unref and then call
>nua_handle_destroy?

No, just call nua_handle_unref() and hope the stack will clean up eventually.
If it helps you, we'll have one more case to later debug the problem with
nua_handle_destroy() and event delivery.

Best regards,
  Mikhail

-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Assertion `sub && sub->sub_ref != 0' failed

[mikhail.zabaluev]

Hi,

Do you explicitly destroy any handles rather than unreffing them?
I remember I had some problem with posthumous event delivery in a corner case,
or something.

Best regards,
  Mikhail

>-Original Message-
>From: [EMAIL PROTECTED] 
>[mailto:[EMAIL PROTECTED] On 
>Behalf Of ext Fabio Margarido
>Sent: Tuesday, December 18, 2007 8:37 PM
>To: sofia-sip-devel@lists.sourceforge.net
>Subject: Re: [Sofia-sip-devel] Assertion `sub && sub->sub_ref 
>!= 0' failed
>
>Bump. Any help anyone? This is kinda urgent.
>Thanks.
>
>On Dec 12, 2007 8:41 AM, Fabio Margarido 
><[EMAIL PROTECTED]> wrote:
>> Hi there,
>>
>> I got this one today when running more performance tests on my
>> application. Is this my fault or could it be a bug?
>> Thanks.
>>
>> nta_outgoing_tcancel: trying to cancel cancelled request
>> tport_vsend(0x8128f20): send truncated for UDP/10.20.90.31:5060
>> nta: ACK (92573398): Input/output error (5) with 
>UDP/[10.20.90.31]:5060
>> nta(0x823bff8): responding 503 Service Unavailable to ACK!
>> tpsip: su_alloc.c:571: su_home_ref: Assertion `sub && 
>sub->sub_ref != 0'
>> failed.
>>
>> Program received signal SIGABRT, Aborted.
>> [Switching to Thread 3076 (LWP 1695)]
>> 0x401f4621 in kill () from /lib/libc.so.6
>> Current language:  auto; currently c
>> (gdb) where
>> #0  0x401f4621 in kill () from /lib/libc.so.6
>> #1  0x4014e26b in raise (sig=6) at signals.c:65
>> #2  0x401f5a53 in abort () from /lib/libc.so.6
>> #3  0x401ede12 in __assert_fail () from /lib/libc.so.6
>> #4  0x400cca9a in su_home_ref (home=0x868db40) at su_alloc.c:571
>> #5  0x400ce518 in su_home_mutex_lock (home=0x868db40) at 
>su_alloc.c:1483
>> #6  0x4005c2ec in msg_destroy (msg=0x868db40) at msg.c:160
>> #7  0x4007fb9c in outgoing_recv (orq=0x86b7ce8, status=487,
>> msg=0x868db40, sip=0x868dbdc) at nta.c:8416
>> #8  0x40075dc3 in agent_recv_response (agent=0x8127d10, 
>msg=0x868db40,
>> sip=0x868dbdc, tport_via=0x8128ea0,
>> tport=0x8128f20) at nta.c:2656
>> #9  0x4007453a in agent_recv_message (agent=0x8127d10, 
>tport=0x8128f20,
>> msg=0x868db40, tport_via=0x8128ea0, now=
>>   {tv_sec = 3406372299, tv_usec = 469809}) at nta.c:2177
>> #10 0x400e8620 in tport_base_deliver (self=0x8128f20, msg=0x868db40,
>> now={tv_sec = 3406372299, tv_usec = 469809})
>> at tport.c:3010
>> #11 0x400e85c5 in tport_deliver (self=0x8128f20, msg=0x868db40,
>> next=0x0, sc=0x0, now=
>>   {tv_sec = 3406372299, tv_usec = 469809}) at tport.c:2999
>> #12 0x400e8244 in tport_parse (self=0x8128f20, complete=1, 
>now={tv_sec =
>> 3406372299, tv_usec = 469809}) at tport.c:2916
>> #13 0x400e8055 in tport_recv_event (self=0x8128f20) at tport.c:2858
>> #14 0x400e7dca in tport_base_wakeup (self=0x8128f20, events=1) at
>> tport.c:2760
>> #15 0x400da20f in su_poll_port_wait_events (self=0x8126af8, 
>tout=38) at
>> su_poll_port.c:590
>> #16 0x400d8598 in su_base_port_run (self=0x8126af8) at
>> su_base_port.c:342
>> #17 0x400d120a in su_root_run (self=0x8127510) at su_port.h:310
>> #18 0x400d8e22 in su_pthread_port_clone_main (varg=0xbf5ff8ec) at
>> su_pthread_port.c:321
>> #19 0x4014b0ce in pthread_start_thread (arg=0xbf3ffc00) at 
>manager.c:291
>> (gdb)

-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Pulling a sofia-sip Patch

[mikhail.zabaluev]

Hi, 

>-Original Message-
>From: ext Jerry Richards [mailto:[EMAIL PROTECTED] 
>Sent: Monday, December 10, 2007 8:06 PM
>To: Zabaluev Mikhail (Nokia-M/Helsinki); 
>sofia-sip-devel@lists.sourceforge.net
>Subject: Pulling a sofia-sip Patch
>
>I noticed when I execute the following commands, I pick up a 
>lot more changes than the one patch "moved message passing 
>into nua_stack".  Is this expected?  Does darcs work such that 
>it will pull down cumulative patches prior to the patch I specify?

Yes, except the patches pulled are probably those which the necessary patch 
depends on
(cannot be applied without applying those patches first).
Just say yes to any patch offered.

Cheers,
  Mikhail
-
SF.Net email is sponsored by: 
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
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 access the payload for 180 ringing (earlymedia)?

[mikhail.zabaluev]

Hi,
 
Use nua_i_state.
 
BR,
  Mikhail




From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ext Lu, 
Qichi
Sent: Thursday, December 06, 2007 12:16 AM
To: sofia-sip-devel@lists.sourceforge.net
Subject: [Sofia-sip-devel] How to access the payload for 180 ringing 
(earlymedia)?



I'm using version 1.12.4 with NUTAG_MEDIA_ENABLE(0). How can I access 
the media information in the 180 ringing response since the sip pointer in the 
nua_r_invite is NULL?

 

 

Charles Lu

-
SF.Net email is sponsored by: 
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Memory Leaks in 1.12.7?

[mikhail.zabaluev]

Hi, 

>-Original Message-
>From: [EMAIL PROTECTED] 
>[mailto:[EMAIL PROTECTED] On 
>Behalf Of ext Jerry Richards
>Sent: Thursday, December 06, 2007 5:04 PM
>To: sofia-sip-devel@lists.sourceforge.net
>Subject: [Sofia-sip-devel] Memory Leaks in 1.12.7?
>
>Hello All,
>
>If I run my application overnight, it apparently exhausts all 
>memory.  I am
>running version 1.12.7.

Pekka has committed a fix to the master darcs repo since.

Get the source from darcs as per tag 'rel-sofia-sip-1_12_7',
then pull the patch "moved messsage passing into nua_stack".

Hope this helps,
  Mikhail

-
SF.Net email is sponsored by: 
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Forked calls

[mikhail.zabaluev]

Hi, 

>-Original Message-
>From: [EMAIL PROTECTED] 
>[mailto:[EMAIL PROTECTED] On 
>Behalf Of ext Fabio Margarido
>Sent: Tuesday, November 13, 2007 3:35 PM
>To: sofia-sip-devel@lists.sourceforge.net
>Subject: [Sofia-sip-devel] Forked calls
>
>is there anything I have to do to tell nua to inform me about forked
>calls? In my tests, when I have a client INVITE transaction that
>receives two 200 OK differing only in the 'To' tag, my callback is
>never informed of 'nua_i_fork'.

Welcome to the club :)
This was discussed just days ago:

http://sourceforge.net/mailarchive/forum.php?thread_name=001001c81caf%24e56b7b20%242c48a8c0%40greyhawk.tonecommander.com&forum_name=sofia-sip-devel

Best regards,
  Mikhail

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] soa example

[mikhail.zabaluev]

Hi, 

>-Original Message-
>From: [EMAIL PROTECTED] 
>[mailto:[EMAIL PROTECTED] On 
>Behalf Of ext Simon Perreault
>Sent: Tuesday, November 06, 2007 10:41 PM
>To: sofia-sip-devel@lists.sourceforge.net
>Subject: [Sofia-sip-devel] soa example
>
>- The RTP source is an external program. Sofia app will start 
>the external 
>program with the right parameters (ie. destination IP and port).
>
>Questions:
>
>- Is this design sound? (Don't tell me to use RTSP. I can't.)

I don't know if it counts for, but that's what we do in Telepathy (for 
bidirectional RTP).

Best regards,
  Mikhail

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] One dialog per handle? (was: Getting Outgoing CSEQ Field)

[mikhail.zabaluev]

 

>-Original Message-
>From: ext Pekka Pessi [mailto:[EMAIL PROTECTED] 
>Sent: Monday, November 05, 2007 2:52 PM
>To: Zabaluev Mikhail (Nokia-M/Helsinki)
>Cc: sofia-sip-devel@lists.sourceforge.net
>Subject: Re: One dialog per handle? (was: Getting Outgoing CSEQ Field)
>
>2007/11/5, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
>> >There can be only one ordinary client transaction going on within a
>> >dialog at a time. Also, there can be only one dialog within handle.
>
>> Wasn't true for me with 1.12.6 and outgoing INVITE -- 
>responses from different dialogs in a forked call were 
>reported against the same handle with 
>nua_r_invite/nua_i_state. This is a matter of some concern, 
>because I was thinking it would be reported with nua_i_fork 
>and a new handle, otherwise there is no easy way to 
>distinguish the dialogs within the same call.
>
>Mikhail - you are correct, the INVITE (and SUBSCRIBE) can end up with
>multiple responses from different dialogs (and UPDATE/NOTIFY requests)
>within the same handle.

Right, but how do I tell the dialogs apart in INVITE responses?

Best regards,
  Mikhail

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

[Sofia-sip-devel] One dialog per handle? (was: Getting Outgoing CSEQ Field)

[mikhail.zabaluev]

Hi,

>-Original Message-
>From: [EMAIL PROTECTED] 
>[mailto:[EMAIL PROTECTED] On 
>Behalf Of ext Pekka Pessi
>Sent: Sunday, November 04, 2007 11:48 PM
>To: Jerry Richards
>Cc: sofia-sip-devel@lists.sourceforge.net
>Subject: Re: [Sofia-sip-devel] Getting Outgoing CSEQ Field
>
>2007/11/1, Jerry Richards <[EMAIL PROTECTED]>:
>> Is there a way for the application to obtain the value of 
>the CSEQ field
>> that sofia-sip sends in an outgoing NOTIFY message?  I need 
>this in order to
>> distinguish multiple outgoing NOTIFY requests with multiple 
>incoming 200
>> OKs.
>
>You are not using notifier() nut nua_notify(), right?
>
>There can be only one ordinary client transaction going on within a
>dialog at a time. Also, there can be only one dialog within handle.

Wasn't true for me with 1.12.6 and outgoing INVITE -- responses from different 
dialogs in a forked call were reported against the same handle with 
nua_r_invite/nua_i_state. This is a matter of some concern, because I was 
thinking it would be reported with nua_i_fork and a new handle, otherwise there 
is no easy way to distinguish the dialogs within the same call.

Best regards,
  Mikhail

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Cannot Accept SUBSCRIBE Request from ApplicationThread

[mikhail.zabaluev]

Hi, 

>-Original Message-
>From: [EMAIL PROTECTED] 
>[mailto:[EMAIL PROTECTED] On 
>Behalf Of ext Jerry Richards
>Sent: Friday, November 02, 2007 6:02 PM
>To: sofia-sip-devel@lists.sourceforge.net
>Subject: [Sofia-sip-devel] Cannot Accept SUBSCRIBE Request 
>from ApplicationThread
>
>I noticed that if I call nua_respond() to accept (202 
>Accepted) an incoming
>SUBSCRIBE request from my application thread, sofia-sip 
>replies with "500
>Responding to a Non-Existing Request" (see trace below with 
>logs of interest
>surrounded by ).
>
>If I call nua_respond() from within the callback function (instead of
>sending a message to application thread), then sofia-sip can 
>transmit the
>message correctly.
>
>Anyone know why this happens?

Another case of a mandatory NUTAG_WITH*, perhaps?

-- 
  Mikhail

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

[Sofia-sip-devel] Transport binding information

[mikhail.zabaluev]

Hi,

Is there a way to retrieve the transport IP address binding currently in use 
(outbound) by the NUA stack?
Same for the inbound transport in incoming requests?

Best regards,
  Mikhail Zabaluev,  Nokia Multimedia
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
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 delay sending SDP on ACK instead of onINVITE

[mikhail.zabaluev]

Hi,

>-Original Message-
>From: [EMAIL PROTECTED] 
>[mailto:[EMAIL PROTECTED] On 
>Behalf Of ext Lu, Qichi
>Sent: Wednesday, October 17, 2007 5:19 PM
>To: Pekka Pessi
>Cc: sofia-sip-devel@lists.sourceforge.net
>Subject: Re: [Sofia-sip-devel] How to delay sending SDP on ACK 
>instead of onINVITE
>
>Thanks! I was using SOA all along. Setting NUTAG_MEDIA_ENABLE(0) and
>using SIP PAYLOAD for SDP info works.

Do you take care to set Content-Type: application/sdp?

SOATAG_USER_SDP_STR gives you that and an additional syntax check, I believe.
However, I'd prefer an ability to construct my own sdp_session_t object...

Best regards,
  Mikhail

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Detecting Far-end Lost or On-Hold

[mikhail.zabaluev]

Hi, 

>-Original Message-
>From: [EMAIL PROTECTED] 
>[mailto:[EMAIL PROTECTED] On 
>Behalf Of ext Pekka Pessi
>Sent: Friday, October 12, 2007 9:56 PM
>To: Jerry Richards
>Cc: sofia-sip-devel@lists.sourceforge.net
>Subject: Re: [Sofia-sip-devel] Detecting Far-end Lost or On-Hold
>
>2007/10/12, Jerry Richards <[EMAIL PROTECTED]>:
>> In SIP, does anyone know how an endpoint can detect that the 
>remote endpoint
>> was lost (e.g. ethernet cable disconnect and no BYE sent)?  
>Is there an RFC
>> or something on this?
>
>The session timer extension (RFC 4028). Please see documentation for
>NUTAG_SESSION_TIMER on its usage with nua:
>
>http://sofia-sip.sourceforge.net/refdocs/nua/nua__tag_8h.html#e
aaa5b49f87dbd527e677214627ad696

But, as I understand, it rather addresses resource use considerations with 
proxies and hence the recommended minimum timeout is close to 1 hour. Not for a 
typical human user with a short attention span ;)

BR,
  Mikhail

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Sofia SIP v1.12.6 Design

[mikhail.zabaluev]

Hi, 

>-Original Message-
>From: [EMAIL PROTECTED] 
>[mailto:[EMAIL PROTECTED] On 
>Behalf Of ext Jerry Richards
>Sent: Friday, October 12, 2007 1:52 AM
>To: 'Pekka Pessi'
>Cc: sofia-sip-devel@lists.sourceforge.net
>Subject: Re: [Sofia-sip-devel] Sofia SIP v1.12.6 Design
>
>Sorry for the dumb question, but how do I incorporate this 
>patch into my
>1.12.6 version?  I went to the darcs site and believe I found the right
>patch:
>
>http://sofia-sip.org/repos/sofia-sip/_darcs/patches/20071005112
>209-55b16-a77
>833d930ab3e9d57c52cd32b01eef5507476d3.gz
>
>Then I copied the contents of this using my Mozilla Firefox 
>browser to a
>file called PekkasPatch located at the top-level of sofia-sip. 
> Then I tried
>the following command, but it didn't work:
>
>patch * PekkasPatch
>
>Do I need to cut-and-paste the changes for each file and patch them
>separately?

http://darcs.net

-- 
  Mikhail

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Checking if SIP message Field is Present

[mikhail.zabaluev]

Hi,

>-Original Message-
>From: [EMAIL PROTECTED] 
>[mailto:[EMAIL PROTECTED] On 
>Behalf Of ext Pekka Pessi
>Sent: Wednesday, October 10, 2007 3:11 PM
>To: Jerry Richards
>Cc: sofia-sip-devel@lists.sourceforge.net
>Subject: Re: [Sofia-sip-devel] Checking if SIP message Field is Present
>
>2007/10/9, Jerry Richards <[EMAIL PROTECTED]>:
>> What is the proper method in the NUA callback function to 
>check whether a
>> SIP message field is valid.  In some cases, if my callback 
>function tries to
>> access a SIP message field that is not present, it can get a 
>segmentation
>> fault.
>
>A non-null pointer in sip_t structure, like
>
>if (!sip->sip_contact) { /* Contact not present */
>}

I noticed that in some nua_r_* events, the sip_t pointer itself may be NULL.
It happens when there's a 904 stack response due to mismatched auth (or an auth 
loop).

-- 
  Mikhail

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Reject calls in nua_i_invite based on SDP

[mikhail.zabaluev]

Hi,





From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ext 
Stefan Leuenberger
Sent: Monday, October 01, 2007 5:53 PM
To: sofia-sip-devel@lists.sourceforge.net
Subject: [Sofia-sip-devel] Reject calls in nua_i_invite based on SDP



Hi there,

when I use nua with automatic SDP (soa) my application gets two

callbacks:

1.  nua_i_invite --> signaling the reception of the invite message

2.  nua_i_state --> reporting the parsing results of the SDP=20

SIP stack and phone-application run in separate processes.

On nua_i_invite I send an INVITE to the phone-application and it starts 
to ring.

If I get nua_i_state I check if the SDP fits. If I recognize that the 
SDP does not fit (e.g. since I only support SRTP calls and the invite only 
contains SDP for plain RTP), I send a 415 "Unsupported Media Type"

and the call is canceled. 

Isn't 488 the proper status code to use here?

BR,
  Mikhail

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] NUTAG_URL() Causes Segmentation Fault If AORContains Two '*'

[mikhail.zabaluev]

Hi, 

>-Original Message-
>From: ext Jerry Richards [mailto:[EMAIL PROTECTED] 
>Sent: Friday, October 05, 2007 5:41 PM
>To: Zabaluev Mikhail (Nokia-M/Helsinki); 
>sofia-sip-devel@lists.sourceforge.net
>Subject: RE: [Sofia-sip-devel] NUTAG_URL() Causes Segmentation 
>Fault If AORContains Two '*'
>
>My phone can use star-codes to activate phone features (e.g. 
>*72 for call forwarding).  And it is possible for a 
>user to activate a feature, then dial a star-code, then press 
>re-dial to introduce a double star-code string (e.g. 
>*73*72).  I'm wondering if protect against this by 
>writing software to remove one of the star-codes prior to 
>invoking nua_handle/nua_invite?  The entire NUTAG_URL() looks 
>like: "sip:[EMAIL PROTECTED]:5060").  I would rather 
>let the user do whatever the user wants to do, so that I don't 
>pre-empt some future capability.
>
>My issue with sofia-sip: I think it should protect itself from 
>generating a segmentation fault.  True?  If you dial the URL 
>above, do you also see the segmentation fault on your platform?

It works for me, but Telepathy-SofiaSIP might do it differently.
Can you look up the location of the crash in a core file or something?

Regards,
  Mikhail
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] NUTAG_URL() Causes Segmentation Fault If AORContains Two '*'

[mikhail.zabaluev]

Hi, 

>-Original Message-
>From: [EMAIL PROTECTED] 
>[mailto:[EMAIL PROTECTED] On 
>Behalf Of ext Jerry Richards
>Sent: Thursday, October 04, 2007 10:11 PM
>To: sofia-sip-devel@lists.sourceforge.net
>Subject: [Sofia-sip-devel] NUTAG_URL() Causes Segmentation 
>Fault If AORContains Two '*'
>
>Does anyone know why I get a Segmentation Fault if I call 
>nua_handle() or
>nua_invite() with an NUTAG_URL() containing two '*' in the AOR?

Don't do that, then? :)
Or maybe, I completely misunderstood the problem. What exactly goes into 
NUTAG_URL?

Best regards,
  Mikhail

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] questions about the sophia-sip/farsightcommunications .

[mikhail.zabaluev]

Hi,





From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ext 
souilem fadi
Sent: Thursday, October 04, 2007 10:31 AM
To: sofia-sip-devel@lists.sourceforge.net
Subject: [Sofia-sip-devel] questions about the 
sophia-sip/farsightcommunications .


the problem is that Telepathy is written in java

??? Check again. Telepathy components are written primarily in C, but 
communicate through D-Bus, an interprocess communication medium.
(Indeed, it is possible to implement a Telepathy connection manager in Java, 
but I don't know of any such implementation in existence).
You might have been misled by the API specification, which is an abstract 
description of D-Bus interfaces.
 
Cheers,
  Mikhail
 
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] questions about the sophia-sip /farsightcommunications .

[mikhail.zabaluev]

Hi,
 
I guess you might want to look at the Telepathy framework: 
http://telepathy.freedesktop.org/wiki/
It provides, among many other things, a mediator between the Sofia-SIP stack 
and the stream engine based on Farsight, in form of the Telepathy-SofiaSIP 
connection manager: http://sourceforge.net/projects/tp-sofiasip
The master Darcs tree for Telepathy-SofiaSIP is available at 
http://projects.collabora.co.uk/darcs/telepathy/telepathy-sofiasip/
You can also use its source code (within the terms of its LGPL license) as an 
example of a Sofia-SIP client utilizing an external media engine.
 
Hope this helps,
  Mikhail




From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ext 
souilem fadi
Sent: Wednesday, October 03, 2007 11:33 AM
To: sofia-sip-devel@lists.sourceforge.net
Subject: [Sofia-sip-devel] questions about the sophia-sip 
/farsightcommunications .


hello 
i' am new in the sophia-sip  community , and now i'm working on a 
videocoference application that uses farsight , to do ireally want to know the 
type of communication and messages between the farsight framework and the 
sophia-sip stack  specially that i noticed that the farsight does'nt do the 
signialing , and it's  the job of the sip stack , so can someone please help me 
to find these structures or messages exchanged between sophia-sip and farsight 
.( i really need to know wich data struct  is responsible of handling the port 
,ip address , event's ..to the farsight ...)
best regards 
Souilem Fadi 

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] SIPS: TCP src-port for registrations

[mikhail.zabaluev]

Hi,




From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ext 
Stefan Leuenberger
Sent: Wednesday, September 12, 2007 10:26 AM
To: sofia-sip-devel@lists.sourceforge.net
Cc: Marcel Reichmuth
Subject: [Sofia-sip-devel] SIPS: TCP src-port for registrations



We use Sofia SIP V1.12.6 for an IP Phone supporting multiple accounts, 
each account uses its own nua instance on a different port. The port is set by 
specifying NUTAG_URL in the nua_create() call.



This works fine for UDP transport. NUA sends requests from the 
transport address specified in NUTAG_URL and receives responses on this 
transport address.



Plain TCP transport is not a requirement and thus not considered.



For SIPS/TLS transport, NUA establishes a listening socket on the 
transport address specified in NUTAG_URL (IP and port) when calling 
nua_create().

Hmm, I was taught that NUTAG_SIPS_URL gives the socket particulars for TLS. 
Have you tried that one?

Best regards,

Mikhail

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Escaped characters in Request-URI

[mikhail.zabaluev]

Hi,

Yes, it looks like a Sofia-SIP bug.
'=' is a reserved character, so the bug is the same as the issue with unescaped 
'@' spotted before.

Maybe I should sit down and write a big patch to that URI code some day...

>-Original Message-
>From: [EMAIL PROTECTED] 
>[mailto:[EMAIL PROTECTED] On 
>Behalf Of ext Fabio Margarido
>Sent: Thursday, August 30, 2007 10:25 PM
>To: sofia-sip-devel@lists.sourceforge.net
>Subject: Re: [Sofia-sip-devel] Escaped characters in Request-URI
>
>Anybody? This is kinda urgent...
>Any help will be much appreciated.
>Thanks
>
>On 8/28/07, Fabio Margarido <[EMAIL PROTECTED]> wrote:
>> Hi there,
>>
>> what do I have to do to force an INVITE to be sent with an 
>escaped '='
>> in the Request-URI? I'm calling nua_invite with something like this:
>>
>> INVITE 
>sip:[EMAIL PROTECTED];voicexml=http://www.123.com/dir/script.v
>xml%3fpar%3dvalue
>>
>> which is changed in the sent package to:
>>
>> INVITE 
>sip:[EMAIL PROTECTED];voicexml=http://www.123.com/dir/script.v
>xml%3fpar=value
>>
>> The receiving side generates an error in this situation. Is there
>> something I can do that will make the message go out exactly as the
>> application asks?
>> Thanks.
>>
>
>---
>--
>This SF.net email is sponsored by: Splunk Inc.
>Still grepping through log files to find problems?  Stop.
>Now Search log events and configuration files using AJAX and a browser.
>Download your FREE copy of Splunk now >>  http://get.splunk.com/
>___
>Sofia-sip-devel mailing list
>Sofia-sip-devel@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
>

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] URI parameter in To header

[mikhail.zabaluev]

Hi,

>-Original Message-
>From: [EMAIL PROTECTED] 
>[mailto:[EMAIL PROTECTED] On 
>Behalf Of ext Jan Van den bosch
>Sent: Tuesday, August 14, 2007 5:45 PM
>To: sofia-sip-devel
>Subject: [Sofia-sip-devel] URI parameter in To header
>
>When I pass the string
>SIPTAG_TO_STR("sip:[EMAIL PROTECTED];group=systeminternal") to
>nua_invite, it shows up in Ethereal as:
>
>To: ;group=systeminternal
>
>How do I get the parameter inside of the brackets, like this:
>
>To: 

I've solved it with a SIPTAG_TO value made using sip_to_create(), the second 
parameter of the latter constructed from the URI string with URL_STRING_MAKE.

Best regards,
  Mikhail

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] non-200 response to incoming MESSAGE

[mikhail.zabaluev]

Hi,

>-Original Message-
>From: [EMAIL PROTECTED] 
>[mailto:[EMAIL PROTECTED] On 
>Behalf Of ext Jan Van den bosch
>Sent: Friday, July 27, 2007 10:43 AM
>To: Pekka Pessi
>Cc: sofia-sip-devel@lists.sourceforge.net
>Subject: Re: [Sofia-sip-devel] non-200 response to incoming MESSAGE
>
>Let's say I want to respond to a specific MESSAGE from outside of the
>callback function, what is the easiest way to differentiate between
>the different MESSAGEs? What structure do I save? SofSipCli keeps a
>list of operation handles that correspond to their respective INVITEs,
>but apparently a handle isn't enough in this case.

I believe it is, but as the other posters noted, you have to keep the saved 
event (NUTAG_WITH*) around as well for nua_respond().

Best regards,
  Mikhail

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Auto-response on incoming MESSAGE

[mikhail.zabaluev]

Hi, 

>-Original Message-
>From: ext Pekka Pessi [mailto:[EMAIL PROTECTED] 
>Sent: Friday, July 06, 2007 5:54 PM
>To: Zabaluev Mikhail (Nokia-M/Helsinki)
>Cc: sofia-sip-devel@lists.sourceforge.net
>Subject: Re: [Sofia-sip-devel] Auto-response on incoming MESSAGE
>
>2007/7/3, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
>> When a MESSAGE request is received by NUA, the stack 
>immediately responds with 200 OK before the callback code can 
>have a go at the message. Is there a way to disable this 
>trigger-happiness similar to NUTAG_AUTOANSWER(0) for call handles?
>
>You can include MESSAGE in the list of methods taken care by
>application with tag
>
>NUTAG_APPL_METHOD("MESSAGE")

Thanks, it worked.

>Please remember all the NUTAG_WITH() jazz when responding

That's a bit of a nuisance for one-shot handles such as one created for 
nua_i_message.

P.S. Does the nua_chat() facility work in 1.12.6?

Best regards,
  Mikhail

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

[Sofia-sip-devel] Auto-response on incoming MESSAGE

[mikhail.zabaluev]

Hi,

When a MESSAGE request is received by NUA, the stack immediately responds with 
200 OK before the callback code can have a go at the message. Is there a way to 
disable this trigger-happiness similar to NUTAG_AUTOANSWER(0) for call handles?

-- 
  Mikhail Zabaluev,  Nokia Multimedia
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] unnecessary unescaping

[mikhail.zabaluev]

Hi, 

>-Original Message-
>From: ext Pekka Pessi [mailto:[EMAIL PROTECTED] 
>Sent: Tuesday, July 03, 2007 2:17 PM
>To: Zabaluev Mikhail (Nokia-M/Helsinki)
>Cc: sofia-sip-devel@lists.sourceforge.net
>Subject: Re: [Sofia-sip-devel] unnecessary unescaping
>
>> BTW, from what I could understand out of the code ;) the 
>hostname part of SIP/SIPS URIs seems to be "canonized" with 
>escaping as well, but in reality it should only be validated 
>to have a FQDN/IPv4/IPv6, everything else makes the URI invalid.
>
>Hm? Hostname should not have any escaped characters.

In 1.12.6, the host name part is subjected to url_canonize2 with the reserved 
set:

785   s = (char *)url->url_host;
786   if (s && !url_canonize2(s, s, SIZE_MAX, RESERVED_MASK))
787 return -1;

-- 
  Mikhail

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] unnecessary unescaping

[mikhail.zabaluev]

Hi,

>-Original Message-
>From: [EMAIL PROTECTED] 
>[mailto:[EMAIL PROTECTED] On 
>Behalf Of ext Pekka Pessi
>Sent: Monday, July 02, 2007 12:01 PM
>To: Jan Van den bosch
>Cc: sofia-sip-devel
>Subject: Re: [Sofia-sip-devel] unnecessary unescaping
>
>> Why is the pctr parameter being unescaped?
>
>All the unreserved chars in URIs are unescaped. The reasoning is to
>make it more straightforward to compare the URIs. Perhaps it would be
>more appropriate to leave everything but scheme, host and port
>unescaped.

It's OK for "!" (it shouldn't have been escaped in the first place), but 
somehow "@" in the parameter became unescaped too, which is wrong because it is 
a reserved URI character.

>>Can I turn this off?

>Only by modifying the source code, see url_d() in url/url.c.

BTW, from what I could understand out of the code ;) the hostname part of 
SIP/SIPS URIs seems to be "canonized" with escaping as well, but in reality it 
should only be validated to have a FQDN/IPv4/IPv6, everything else makes the 
URI invalid.

My 2 cents,
  Mikhail

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] changing sofia sip to use libevent?

[mikhail.zabaluev]

Hi,
 
With GLib mainloop it works the other way around: SU port integrates into the 
mainloop as an event source. I don't know if custom event sources are possible 
in libevent.
 
Best regards,
  Mikhail




From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ext 
wensong zhang
Sent: Friday, June 29, 2007 11:09 AM
To: sofia-sip-devel@lists.sourceforge.net
Subject: [Sofia-sip-devel] changing sofia sip to use libevent?


We want to use sofia sip stack with our modules such as STUN, TURN and 
ICE. Those modues use libevent library for event handling. We still like to 
keep single-thread event-driven architecture.

There are probably two ways to integrate: one is to change those 
modules to use sofia event loop interface, it seems some work; the other is to 
change sofia to use libevent, though sofia has already supported the 
select/poll/epoll/kqueue/devpoll event mechanism. 

If I want to give a try to the latter, do I just need to make a 
su_libevent_port.c file to hook up in libevent?


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] SDP Events Reported to User Application

[mikhail.zabaluev]

Hi, 

>-Original Message-
>From: [EMAIL PROTECTED] 
>[mailto:[EMAIL PROTECTED] On 
>Behalf Of ext Jerry Richards
>Sent: Tuesday, June 26, 2007 8:00 PM
>To: sofia-sip-devel@lists.sourceforge.net
>Subject: [Sofia-sip-devel] SDP Events Reported to User Application
>
>Does sofia-sip ALWAYS report SDP changes to the application?
>
>Does sofia-sip suppress reporting of SDP events when it does 
>not differ from what was last reported?

I've found experimentally this is not the case, at least when NUTAG_AUTOANSWER 
is set to false.
The reason being, nua callstate changes when a re-INVITE is received and 
nua_i_state is issued with the new callstate plus the remote SDP which may or 
may not differ from the previous one.

I solved this by keeping the previous sdp_media_t description and checking for 
changes with sdp_session_cmp(). Media stream descriptions can also be compared 
piecewise with sdp_media_cmp(), and so further down.

Hope this helps,
  Mikhail
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] nua_create() Fails With No Delay

[mikhail.zabaluev]

Hi,

The shutdown is asynchronous; does your application wait for nua_r_shutdown 
with status >=200 to make sure the NUA instance has been shut down?

Best regards,
  Mikhail

>-Original Message-
>From: [EMAIL PROTECTED] 
>[mailto:[EMAIL PROTECTED] On 
>Behalf Of ext Jerry Richards
>Sent: Friday, June 22, 2007 9:54 PM
>To: sofia-sip-devel@lists.sourceforge.net
>Subject: [Sofia-sip-devel] nua_create() Fails With No Delay
>
>I noticed in one of your previous reply (below), you recommend 
>delaying 500
>milliseconds between mulitiple registrations.  Why is this necessary?
>
>I'm asking this because nua_create() is failing in the 
>following scenario:
>   1) nua_create() (port 5061)
>   2) Register Line
>   3) Unregister Line
>   4) Shutdown Line
>   5) nua_create() (port 5061)
>   .. nua_create() returns zero
>   6) Re-register Line
>
>However, if I place a 500 millisecond delay between steps 4 
>and 5, then the
>process completes succesfully.

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

[Sofia-sip-devel] Patch: make NUTAG_WITH_SAVED really NULL-proof

[mikhail.zabaluev]

 <>  
Hi,

Here's a patch to make NUTAG_WITH_SAVED usable in cases the nua_saved_event_t 
slot is NULL-initialized.
Also, corrected the parameter value in the apidoc.

BR,
  Mikhail


sofia-sip-nutag-with-saved-crashproof.dpatch
Description: Binary data
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Accessing SOATAG_REMOTE_SDP_STR() In CallbackFunction

[mikhail.zabaluev]

Hi,

I believe the SDP is expected only with nua_i_state event, and only if 
respective SOA flags are true.

BR,
  Mikhail

>-Original Message-
>From: [EMAIL PROTECTED] 
>[mailto:[EMAIL PROTECTED] On 
>Behalf Of ext Jerry Richards
>Sent: Wednesday, May 23, 2007 2:17 AM
>To: sofia-sip-devel@lists.sourceforge.net
>Subject: [Sofia-sip-devel] Accessing SOATAG_REMOTE_SDP_STR() 
>In CallbackFunction
>
>Hello,
>
>The following snippet shows how I am attempting to extract the
>SOATAG_REMOTE_SDP_STR() in my callback function, however, it 
>always comes up
>with a NULL string.  What am I doing wrong?
>
>void ce_SipEventCb(nua_event_t event,
>  int status,
>  char const *phrase,
>  nua_t *nua,
>  nua_magic_t *magic,
>  nua_handle_t *nh,
>  nua_hmagic_t *hmagic,
>  sip_t const *sip,
>  tagi_t tags[])
>{
>   ...
>   char remoteSDP[120];
>   tl_gets(tags, SOATAG_REMOTE_SDP_STR(remoteSDP), TAG_END());
>   printf("   remoteSDP='%s'\n", remoteSDP);
>   ...
>}

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

[Sofia-sip-devel] Python bindings (Was: working stun - symmetric response routing anyone ?)

[mikhail.zabaluev]

Hi,

My two cents...

I've also been thinking about what would it take to create Python bindings for 
Sofia-SIP.
The tag system maps rather nicely to Python's named function parameters. 
However, to pass the parameters down to the stack you'll have to call 
set_params/set_hparams repeatedly, one tag at a time.

Also, I'd like to see some object orientation instead of straightforward 
function-to-function mapping.
And, as the stack is event-based, perhaps integration with Twisted will be 
great?

Best regards,
  Mikhail

>-Original Message-
>From: [EMAIL PROTECTED] 
>[mailto:[EMAIL PROTECTED] On 
>Behalf Of ext Martti Mela
>Sent: Tuesday, May 22, 2007 6:47 PM
>To: sofia-sip-devel@lists.sourceforge.net
>Subject: Re: [Sofia-sip-devel] working stun - symmetric 
>response routing anyone ?
>
>Hey Marcus,
>
>Great to hear that you created the python bindings! Could you 
>send the code
>for me? I'd be happy to try that out and maybe we could consider either
>merging that to our tree or to create another public project for them?
>
>All the best,
>
>Martti
>
>
>On 5/16/07 6:42 PM, "ext Marcus Priesch" 
><[EMAIL PROTECTED]> wrote:
>
>> Dear All,
>> 
>> first of all, thanks for that great piece of software, i am 
>using it now
>> for quite a while and it's really nice ;) - under python via ctypes -
>> YEAH !

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] sofia-sip to Gizmo - TCP Timeout

[mikhail.zabaluev]

 

>-Original Message-
>From: ext Pekka Pessi [mailto:[EMAIL PROTECTED] 
>Sent: Wednesday, May 09, 2007 2:47 PM
>To: Zabaluev Mikhail (Nokia-M/Helsinki)
>Cc: [EMAIL PROTECTED]; 
>sofia-sip-devel@lists.sourceforge.net
>Subject: Re: [Sofia-sip-devel] sofia-sip to Gizmo - TCP Timeout
>
>2007/5/9, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
>> From my experience, their TCP proxy does not care if "rport" 
>is in the Via line; it never sends back received/rport for a 
>REGISTER. To add insult to injury, they have a different idea 
>of our Contact URI than we communicate to them (ours is 
>usually in a private IP address range and does not have 
>"transport=tcp" parameter, and that might be part of the 
>problem). After our UA has registered using the TCP 
>connection, they prefer to send it incoming requests via UDP 
>from a different host. No wonder that doesn't get through most 
>of the time.
>
>Have you managed to get TCP working at all,

Halfway; incoming calls/messages do not always get through this SIPphone 
brokenness.
By mercy of our NAT setup, sometimes I get those incoming requests via UDP.

>or should the Gizmo users
>just use 
>NTATAG_DEFAULT_PROXY("sip:sipproxy01.sipphone.com;transport=udp")?

That's a good workaround for now.

Best regards,
  Mikhail

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] sofia-sip to Gizmo - TCP Timeout

[mikhail.zabaluev]

Hi, 

>-Original Message-
>From: [EMAIL PROTECTED] 
>[mailto:[EMAIL PROTECTED] On 
>Behalf Of ext Pekka Pessi
>Sent: Tuesday, May 08, 2007 11:10 PM
>To: [EMAIL PROTECTED]
>Cc: sofia-sip-devel@lists.sourceforge.net
>Subject: Re: [Sofia-sip-devel] sofia-sip to Gizmo - TCP Timeout
>
>> The service connects ok using TCP and sends an OPTIONS 
>request, but after 30
>> seconds has a timeout. The OPTIONS request is retried using 
>UDP which is
>> successful.
>
>> RFC3261 (18.2.2) says that responses to requests must be sent via any
>> existing reliable transport. So I think this is a problem on 
>the Gizmo
>> end.
>
>Probably yes. Now I wonder if there is some magic they require in the
>Via line, for instance.

>From my experience, their TCP proxy does not care if "rport" is in the Via 
>line; it never sends back received/rport for a REGISTER. To add insult to 
>injury, they have a different idea of our Contact URI than we communicate to 
>them (ours is usually in a private IP address range and does not have 
>"transport=tcp" parameter, and that might be part of the problem). After our 
>UA has registered using the TCP connection, they prefer to send it incoming 
>requests via UDP from a different host. No wonder that doesn't get through 
>most of the time.

-- 
  Mikhail

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Patch: unblock connect()

[mikhail.zabaluev]

Hi, 

I must say the code seems to be all ready for non-blocking operation of 
connect() at least for POSIX-based platforms, it only misses the non-blocking 
flag setting before calling it (however, immediately afterwards there is a wait 
creation which sets the flag as well).

Thanks for all the good work,
  Mikhail

>-Original Message-
>From: ext Pekka Pessi [mailto:[EMAIL PROTECTED] 
>Sent: Tuesday, May 08, 2007 11:43 AM
>To: Zabaluev Mikhail (Nokia-M/Helsinki)
>Cc: sofia-sip-devel@lists.sourceforge.net
>Subject: Re: [Sofia-sip-devel] Patch: unblock connect()
>
>2007/5/7, Mikhail Zabaluev <[EMAIL PROTECTED]>:
>> Here's a one-line patch that:
>> a) passes the test suite and our application smoke test runs;
>> b) makes a difference when the Sofia root is set to the 
>non-threading mode.
>
>> If not for blocking connect(), the Sofia-SIP coexists in the 
>same thread
>>   with the D-Bus service in our GLib mainloop. This patch removes the
>> single discovered temptation for our project to enable 
>threading, which
>> would be a change for the worse in our platform. 
>Additionally, it makes
>> for better behavior when connect() blocks, as the stack then 
>times out
>> accordingly to its own preference, and not what the operating system
>> deems good for connect().
>
>I'll test this on win32 and apply if it seems to work there, too. I
>though I moved the nonblocking code to su_socket(), but it looks like
>I did not.

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

[Sofia-sip-devel] Outbound proxy and dialogs (was: Registration and Session Border Controllers)

[mikhail.zabaluev]

Hi, 

>-Original Message-
>From: [EMAIL PROTECTED] 
>[mailto:[EMAIL PROTECTED] On 
>Behalf Of ext Pekka Pessi
>Sent: Wednesday, May 02, 2007 8:05 PM
>To: Matthew O Connor
>Cc: sofia-sip-devel@lists.sourceforge.net
>Subject: Re: [Sofia-sip-devel] Registration and Session Border 
>Controllers
>
>You can add NTATAG_DEFAULT_PROXY() (also known as NUTAG_PROXY()) with
>SBC URI to the list of tags given to nua_*() functions. There is a
>catch, however, the proxy URI is used only with the initial request,
>not with subsequent requests within the dialog.
>
>You can change the default proxy for all requests by including
>NUTAG_PROXY() with nua_create() or nua_set_params().

That's interesting with regard to my recent feature request.
So, is there a way after all to make Sofia-SIP honor a dialog-established route 
and have an outbound proxy used by default?
If I supply the registrar proxy in nua_set_params() and only put NUTAG_PROXY() 
in nua_invite() et al., will it do the trick?

Best regards,
  Mikhail

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

[Sofia-sip-devel] Announce: telepathy-sofiasip 0.3.12

[mikhail.zabaluev]

Hello,

We've put out the first public source release of Telepathy-SofiaSIP connection 
manager.

The source tarball for release 0.3.12 is available at:
http://sourceforge.net/project/showfiles.php?group_id=191149&package_id=224422&release_id=496988

New in this release:
   * Implemented "foreign" realm authentication using extra credentials.
   * Connection preferences for STUN server are propagated as media stream 
properties.
   * Uses new handle repo API from libtelepathy-glib.
   * Temporary fix for mismatches of m= lines in SDP exchanges.

The project page:
http://sourceforge.net/projects/tp-sofiasip

Enjoy,
  Mikhail Zabaluev,  Nokia Multimedia
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Authentication state machinery

[mikhail.zabaluev]

Hi, 

>-Original Message-
>From: ext Pekka Pessi [mailto:[EMAIL PROTECTED] 
>Sent: Monday, March 19, 2007 2:09 PM
>To: Zabaluev Mikhail (Nokia-M/Helsinki)
>Cc: sofia-sip-devel@lists.sourceforge.net
>Subject: Re: [Sofia-sip-devel] Authentication state machinery
>
>> May it be that nua_authenticate() (possibly with no 
>NUTAG_AUTH parameters?) is mandatory to handle the 
>authentication responses?
>
>That would be one option.
>
>Currently, I believe, the stack does not try to send same credentials
>twice if they have been rejected (without stale parameter). I'm afraid
>it is up to the application to avoid supplying same credentials.

Note also it's a MUST NOT in the RFC, so the stack might better detect such 
resubmission from the app (for the same realm and nonce) and synthesize a 403 
error right away without going to the wire, which does not seem to be the case 
with 1.12.5.

Regards,
  Mikhail

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Authentication state machinery

[mikhail.zabaluev]

Hi,

There is another discovery: a call does not get terminated cleanly if a 401/407 
response to INVITE is not handled with nua_authenticate(), e.g. due to absence 
of credentials to submit. Instead, after the final ACK is sent as per the call 
model, an orphaned ACK "transaction" is left hanging that temporarily prevents 
proper shutdown later. I'll have to check though if that's an artefact of our 
application logic, probably by creating a simplified test.
May it be that nua_authenticate() (possibly with no NUTAG_AUTH parameters?) is 
mandatory to handle the authentication responses?

BR,
  Mikhail

>-Original Message-
>From: [EMAIL PROTECTED] 
>[mailto:[EMAIL PROTECTED] 
>Sent: Wednesday, March 14, 2007 2:28 PM
>To: sofia-sip-devel@lists.sourceforge.net
>Subject: [Sofia-sip-devel] Authentication state machinery
>
>Hi,
>
>I have an issue handling 401 or 407 authentication challenges 
>for which I haven't found an answer in the documentation.
>It is allowed for the server to repeat the challenge if the 
>preceding authentication fails; the client must not reattempt 
>the authentication that has just been rejected.
>In my case, the handler is called every time for repeated 
>401/407 responses, and in absence of avoidance logic, ends up 
>repeating the response Authorization header exactly. However, 
>the stack seems to give up after a number of iterations. Is it 
>supposed to be handled by the stack automatically, or shall 
>the application detect such loops, checking if the nonce and 
>the realm are the same as the last time?

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

[Sofia-sip-devel] Authentication state machinery

[mikhail.zabaluev]

Hi,

I have an issue handling 401 or 407 authentication challenges for which I 
haven't found an answer in the documentation.
It is allowed for the server to repeat the challenge if the preceding 
authentication fails; the client must not reattempt the authentication that has 
just been rejected.
In my case, the handler is called every time for repeated 401/407 responses, 
and in absence of avoidance logic, ends up repeating the response Authorization 
header exactly. However, the stack seems to give up after a number of 
iterations. Is it supposed to be handled by the stack automatically, or shall 
the application detect such loops, checking if the nonce and the realm are the 
same as the last time?

Regards,
  Mikhail
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

[Sofia-sip-devel] ANN: Telepathy-SofiaSIP

[mikhail.zabaluev]

Hello,
 
I'm happy to announce the long-awaited release of Telepathy-SofiaSIP, a 
Telepathy connection manager component adding support for IETF SIP protocol, 
into the free software world.
 
As can be guessed from the name, it's a thin layer wiring the Sofia-SIP 
protocol stack into the Telepathy framework (http://telepathy.freedesktop.org).
The project is now hosted at SourceForge: 
http://sourceforge.net/projects/tp-sofiasip/ ; you can check out the source 
from the SourceForge's SVN repository.
More updates will follow; hopefully, we'll get a proper project webpage soon.
 
Enjoy & Best regards,
  Mikhail
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
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 Lines

[mikhail.zabaluev]

 

>-Original Message-
>From: [EMAIL PROTECTED] 
>[mailto:[EMAIL PROTECTED] On 
>Behalf Of ext Jerry Richards
>Sent: Friday, February 02, 2007 7:03 PM
>To: sofia-sip-devel@lists.sourceforge.net
>Subject: [Sofia-sip-devel] Multiple Lines
>
>Is it okay if I use Sofia-SIP to develop a SIP phone that has 
>multiple (up to 50) Lines?  Each line will register with the 
>SIP proxy server.
>
>Do I need to call su_root_create() and nua_create() for each 
>line?

At least su_root_create() is supposed to be once per process.

>Does that mean I need a unique callback function for 
>each line?

Of course not, you only need some accounting for the handles your callback will 
be called with.

HTH,
  Mikhail

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel