headers
vadim@mbdsys.com | 1 Jul 2006 02:30

Re: help! how to develop a softphone?

You can try and look at Verona voip toolkit at open.mbdsys.com

mt816 <at> sohu.com wrote:

>hi, <p>I want to develop a simple softphone. I prepare to implement it using the eXosip2, osip2 and ortp. I
am confused the eXosip2, eXosip and osip2. what is the difference of them? is there better library to
finish the softphone? <p><p><p>To develop a softphone by c/c++, do you have good idea or adivice?
<p><p>Thanks a lot!<p> <p> <p>
>  
>
>  
>
Vadim
Permalink | Reply | 0 comments |
headers
saidulu earlapati | 1 Jul 2006 07:34
Picon

Re: help! how to develop a softphone?

Hi

there is a Open SOurce on sip softphone i.e. LINPHONE which is using the
eXosip2, osip2, ortp which is developed in simple 'c' lang..

i think that osip2 provides the API's for SIP and eXosip contains the
functions which is the developement of LINPHONE

Saidulu Earlapati

-----------------  Original message -------------------------------------
Message: 1
Date: Fri, 30 Jun 2006 20:26:45 +0800 (CST)
From: < mt816 <at> sohu.com>
Subject: [Sip-implementors] help! how to develop a softphone?
To: <sip-implementors <at> cs.columbia.edu>
Message-ID:
       <7928612.1151670405848.JavaMail.postfix <at> mx33.mail.sohu.com>
Content-Type: text/plain; charset="gb2312"

hi, <p>I want to develop a simple softphone. I prepare to implement it using
the eXosip2, osip2 and ortp. I am confused the eXosip2, eXosip and osip2.
what is the difference of them? is there better library to finish the
softphone? <p><p><p>To develop a softphone by c/c++, do you have good idea
or adivice? <p><p>Thanks a lot!<p> <p> <p>
Permalink | Reply | 0 comments |
headers
mhofmann | 2 Jul 2006 18:17
Favicon

When I have to use 406 Not Acceptable!

Hello,

I have a question about using 406 Not Acceptable.

Is it right that I have to use the 406 if I got an INVITE with a Content-Type
header which I do not support?

If yes, should I set the Accept header?

If no, which response code should I use?

Thanks in advance.

Markus
Permalink | Reply | 0 comments |
headers
SungWoo Lee | 3 Jul 2006 03:59

SIP Proxy Load balancing

Dear,

I guess I have seen something like SIP Proxy Load balancing and wondering this is well-used
or recently-demanded functionality in the industry. Currently my SIP stack allows a single
outbound proxy setting at a moment as stated in RFC3261. However, Proxy Load balancing came from
an idea of letting one UAC have multiple SIP Proxies for Load balancing purpose.

Does any of SIP implementors here know or experience this kinda Proxy Load balancing? If so,
could you let me know where I can get any related reference document for it? (RFCs or whatever)

Thanks always.

Sean
Permalink | Reply | 1 comment |
headers
Attila Sipos | 3 Jul 2006 08:35

Re: When I have to use 406 Not Acceptable!


Hi,

>> Is it right that I have to use the 406 if I got an INVITE 
>> with a Content-Type header which I do not support?

Not really.
You should use 415...

(from "8.2.3 Content Processing" in RFC3261)
   If there are any bodies whose type (indicated by the
   Content-Type), language (indicated by the Content-Language) or
   encoding (indicated by the Content-Encoding) are not understood, and
   that body part is not optional (as indicated by the Content-
   Disposition header field), the UAS MUST reject the request with a 415
   (Unsupported Media Type) response.

Regards,

Attila

Attila Sipos
Software Engineer
http://www.vegastream.com

>> -----Original Message-----
>> From: sip-implementors-bounces <at> cs.columbia.edu
>> [mailto:sip-implementors-bounces <at> cs.columbia.edu]On Behalf Of
>> mhofmann <at> nero.com
>> Sent: 02 July 2006 17:17
(Continue reading)

Permalink | Reply | 0 comments |
headers
priya pandit | 3 Jul 2006 11:49
Picon

Stateful proxy behavior

Hi all,

When a stateful proxy receive a message and if it not able to process
and forward that message due to some internal errors, can it send an
error response back to the previous network element? Is that allowed
or if not, what is expected out of the Proxy in such scenarios?

Should it drop the message abruptly?

Thanks,
Priya.
Permalink | Reply | 2 comments |
headers
Arthur Moroz | 3 Jul 2006 12:30
Picon
Favicon

About selecting the external line at SIP-PSTN gateway

Hi,

I'm wondering if there's more or less standard way to
specify the choosen external line (port) at the
SIP-PSTN gateway. More specific, the question is what
should be the initial INVITE message from the SIP
phone or proxy to the hardware gateway to tell it to
use specific line for outbound call?

Thanks in advance,
Arthur

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com
Permalink | Reply | 1 comment |
headers
Nataraju A B | 3 Jul 2006 13:26
Favicon

Re: Stateful proxy behavior

> 
> Hi all,
> 
> When a stateful proxy receive a message and if it not able to process
> and forward that message due to some internal errors, can it send an
> error response back to the previous network element? Is that allowed
> or if not, what is expected out of the Proxy in such scenarios?
> 
> Should it drop the message abruptly?
[ABN] it should behave like UAS, 
section 16.1 is clear on this... 

<3261 - snip
   Being a proxy is a logical role for a SIP element.  When a request
   arrives, an element that can play the role of a proxy first decides
   if it needs to respond to the request on its own.  For instance, the
   request may be malformed or the element may need credentials from the
   client before acting as a proxy.  The element MAY respond with any
   appropriate error code.  When responding directly to a request, the
   element is playing the role of a UAS and MUST behave as described in
   Section 8.2.

/snip - 3261>

> 
> Thanks,
> Priya.
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors <at> cs.columbia.edu
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rajnish Jain | 3 Jul 2006 13:44

Re: About selecting the external line at SIP-PSTNgateway

Pls. refer to the following draft:
http://www.ietf.org/internet-drafts/draft-ietf-iptel-trunk-group-08.txt

Here is an example of an INVITE's R-URI from this draft:

   INVITE sip:+16305554554;tgrp=TG2-1;
     trunk-context=example.com <at> gw2.example.com;user=phone SIP/2.0

The granularity at which this draft addresses the PSTN interface is a
trunk-group (tgrp). For most routing purposes this level of addressability
is sufficient. 

It seems that you're looking for a bit finer granularity (i.e. a 'port'
number). A trunk is an overloaded term in PSTN. I believe a trunk can be as
small as a circuit (e.g. a CIC in SS7). And of course a trunk-group can be
as small as a single trunk. While this would be a bit tedious from an OAM&P
perspective, if the producer and consumer of the tgrp= param are configured
this way, you can achieve the granularity of a single circuit (or port). 

Rajnish 

-----Original Message-----
From: sip-implementors-bounces <at> cs.columbia.edu
[mailto:sip-implementors-bounces <at> cs.columbia.edu] On Behalf Of Arthur Moroz
Sent: Monday, July 03, 2006 6:30 AM
To: sip-implementors <at> cs.columbia.edu
Subject: [Sip-implementors] About selecting the external line at
SIP-PSTNgateway

Hi,
(Continue reading)

Permalink | Reply | 0 comments |
headers
ravishankar.shiroor | 4 Jul 2006 05:40

Re: Clarification regarding UPDATE method


Hi Ashutosh,

SDP offer in the UPDATE can be different from that of the INVITE.

Regards,
Ravi.

--

Ravishankar. G. Shiroor
Wipro Technologies, Bangalore.

ravishankar.shiroor <at> wipro.com
--

> -----Original Message-----
> From: sip-implementors-bounces <at> cs.columbia.edu
> [mailto:sip-implementors-bounces <at> cs.columbia.edu] On Behalf
> Of Ashutosh P - SPAN
> Sent: Tuesday, June 27, 2006 12:42 PM
> To: sip-implementors <at> cs.columbia.edu
> Subject: [Sip-implementors] Clarification regarding UPDATE method
>
>
> BlankHi All,
> I have some doubt regarding the UPDATE method.
> When we send an UPDATE  method, it is basically to update the
> parameters of a session and has no impact on a dialog.
>
(Continue reading)

Permalink | Reply | 0 comments |

Gmane