headers
Abdul Lateef | 1 Nov 2005 13:28
Picon
Favicon

Callback Advice needs?

Hi friends,

I have a samall question about VoIP Callback. Is SER
supports Callback systme?
Is Callback needs some special hardware? 

i have my PSTN phone number i want
to call this number after two ring the call will be
disconnect and the Callback will start to call back to
the caller ID and it should prompt to enter pin id
which will authunticate via freeradius.if the
authuntication is valid it will give some beep for
dialing the international number.

Any kind of suggestion will be hearty appriciated.

--------
Yours,
Abdul Lateef
Computer Programmer
HATIF COM
Mob: +974 - 5405022
Tel: +974 - 4883068
ICQ: 276994704
YM!: abdul_zu
Fax: +974 - 4883063
Doha Qatar
http://www.hatif.com
(Continue reading)

Permalink | Reply | 0 comments |
headers
Matthew Gardiner | 1 Nov 2005 16:59

SIP Authentication

Hi all,

I have an existing SIP gateway product to which I am currently extending to
answer authentication challenges. The client (UAC) is essentially an
automaton, which in response to a challenge say for realm="X" would build a
response based on user="Y" and password="Z". My problem lies with the
scenario which could occur if the password possessed by the client is wrong,
then I believe it would quite easy for the following situation to occur,
given that the client is an automaton:

		|					|
caller		|----------------invite---------------------------------->|
proxy
		|<---------------401-------------------------------------|
		|-----------------ack----------------------------------->|
		|					|
		|----------------invite---------------------------------->|
		|<---------------401-------------------------------------|
		|-----------------ack----------------------------------->|
		|					|
		|----------------invite---------------------------------->|
		|<---------------401-------------------------------------|
		|-----------------ack----------------------------------->|
		|					|
		|	etc. etc.			|
		|					|

That is, the client supplies bad credentials forever and the server forever
responds with 401s.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Vijaya Bhaskara Reddy K | 1 Nov 2005 17:04

RE: Can we expect maddr, port,transport params in Tel URI


Hi ,

  Can we expect maddr, port, transport params in Tel URI.

Thanks,
Bhaskar.

"SASKEN RATED THE BEST COMPANY TO WORK FOR IN INDIA - SURVEY 2004 conducted by the BUSINESS TODAY
-Mercer-TNS India"

                           SASKEN BUSINESS DISCLAIMER
This message may contain confidential, proprietary or legally Privileged information. In case you are
not the original intended Recipient of the message, you must not, directly or indirectly, use, Disclose,
distribute, print, or copy any part of this message and you are requested to delete it and inform the
sender. Any views expressed in this message are those of the individual sender unless otherwise stated.
Nothing contained in this message shall be construed as an offer or acceptance of any offer by Sasken
Communication Technologies Limited ("Sasken") unless sent with that express intent and with due
authority of Sasken. Sasken has taken enough precautions to prevent the spread of viruses. However the
company accepts no liability for any damage caused by any virus transmitted by this email
Permalink | Reply | 1 comment |
headers
Brett Tate | 1 Nov 2005 19:07
Favicon

RE: Can we expect maddr, port, transport params in Tel URI

> Can we expect maddr, port, transport params in Tel URI.

There is no RFC which presents these parameters within a Tel URI.
Permalink | Reply | 0 comments |
headers
Brett Tate | 1 Nov 2005 21:55
Favicon

offer-answer rules when 100rel not used

Is it valid to send an offer within an UPDATE if the INVITE's 18x answer was
not sent requiring 100rel?  Does the answer to the question change if the
18x was sent over TCP?

RFC 3261 section 13.2.1 could be interpreted that the answer can be within a
18x if it is received by the UAC.  However RFC 3311's interpretation appears
to require 100rel instead of just receiving the 18x.

RFC 3261 section 13.2.1:

"If the initial offer is in an INVITE, the answer MUST be in a reliable
non-failure message from UAS back to UAC which is correlated to that INVITE.
For this specification, that is only the final 2xx response to that INVITE.
That same exact answer MAY also be placed in any provisional responses sent
prior to the answer.  The UAC MUST treat the first session description it
receives as the answer, and MUST ignore any session descriptions in
subsequent responses to the initial INVITE."

"Concretely, the above rules specify two exchanges for UAs compliant to this
specification alone - the offer is in the INVITE, and the answer in the 2xx
(and possibly in a 1xx as well, with the same value), or the offer is in the
2xx, and the answer is in the ACK."

RFC 3311 section 5.1:

"If the UPDATE is being sent before completion of the initial INVITE
transaction, and the initial INVITE contained an offer, the UPDATE can
contain an offer if the callee generated an answer in a reliable provisional
response, and the caller has received answers to any other offers it sent in
either PRACK or UPDATE, and has generated answers for any offers it received
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jeroen van Bemmel | 1 Nov 2005 22:14
Picon

Re: SIP Authentication

Matthew,

IMO the proper abstraction here would be an object representing a "call 
attempt", not a call id. It is recommended to use new Call-ID and From-tag 
for each authentication attempt (see authentication examples draft)

So your callback function would end up something like this:

virtual bool challengeReceived( /*in*/ CallAttempt &call, /*in*/ const char* 
realm );

CallAttempt would then e.g. keep track of how many times authentication was 
tried, perhaps something like this:

class CallAttempt {

    /** Sends an INVITE with the supplied credentials attached **/
    public: bool authenticate( const char* realm, const char* user, const 
char* password );
};

What you should keep track of, is not how often authentication was tried, 
but which credentials were tried and failed. A client should not attempt the 
same credentials twice, but may try different usernames + passwords. A 
simple approach could be to only remember the last credentials used, and 
fail when the application tries the same thing again (return false)

Regards,

Jeroen
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Kyzivat | 1 Nov 2005 22:45
Picon
Favicon

Re: offer-answer rules when 100rel not used

Brett,

IMO, if you sent an invite w/offer and received an unreliable 1xx with 
SDP, you may *not* send another offer. Doing so would violate 
offer/answer because you have not yet received an answer. The sdp in the 
unreliable 1xx is technically not an answer - it is a sort of "preview" 
of what the offer will be. The offer itself will come in the first 
reliable response to the invite.

So the answer to your question is: NO.

	Paul

Brett Tate wrote:
> Is it valid to send an offer within an UPDATE if the INVITE's 18x answer was
> not sent requiring 100rel?  Does the answer to the question change if the
> 18x was sent over TCP?
> 
> RFC 3261 section 13.2.1 could be interpreted that the answer can be within a
> 18x if it is received by the UAC.  However RFC 3311's interpretation appears
> to require 100rel instead of just receiving the 18x.
> 
> 
> RFC 3261 section 13.2.1:
> 
> "If the initial offer is in an INVITE, the answer MUST be in a reliable
> non-failure message from UAS back to UAC which is correlated to that INVITE.
> For this specification, that is only the final 2xx response to that INVITE.
> That same exact answer MAY also be placed in any provisional responses sent
> prior to the answer.  The UAC MUST treat the first session description it
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hensel, Daniela | 2 Nov 2005 09:04
Favicon

How to filter SIP messages?

Hi all,

I have a question that seems to be very easy at the beginning. But after
having a closer look to it, it is not so easy anymore. I hope somebody
has an answer for me?!

My question is: How can I idenify SIP Messages (or TCP packets containig
SIP messages) to filter them e.g. for QoS?

I mean, a SIP message has no real header, that says 'This is a SIP
message'. And using TCP or UDP, there is no field in the headers
identifying the protocol that is encapsulated.

The only idea is to use the default port 5060 for SIP messages (to
filter all messages that use this port), but what will happen, if the
port changes, or if other protocols use this port as well?

Is there any other possibility to identify SIP messages?

Thank you very much for your support!

Best regards

Daniela

###########################################

This message has been scanned by F-Secure Anti-Virus for Microsoft
Exchange.
For more information, connect to http://www.F-Secure.com/
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mustafa Ozveren | 2 Nov 2005 09:57
Picon

SIP message and Cseq incrementation

Hello All,

Just a question about cseq incrementation.

Is the incrementation of CSEQ must be +1 at each request or incrementation
of type +n ( n > 1 ) is valid ?
Because I am reading in Vocal code that incrementation +n seems to be valid.

Thanks,
Mustafa
Permalink | Reply | 2 comments |
headers
khairunnisa.hassanali | 2 Nov 2005 10:10

Query on draft-ietf-simple-event-list-07 "A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists"


Hi,

      I am going through draft-ietf-simple-event-list-07 and have a query
on Section 7

Section 7.1 specifies that  "any RLS which uses SIP back-end  subscriptions
to acquire information about the resources in a  resource list MUST be able
to act as an authentication service as  defined in [7], provided that local
administrative policy allows them  to do so."

If a RLS does not act as an authentication service, the procedure described
in Section 7.2 should be followed stated as
"RLSes which are in a  different domain than the subscriber on whose behalf
they are  creating back-end susbcriptions SHOULD subscribe to the resources
using their own identity.  By doing so, the RLS will generally obtain  only
the resource information which is made publicly available."

The limitation of the above as stated is the fact that the RLS will have
access to  only the resource information which is made publicly available
and NOT the information that would otherwise have been available had the
RLS subscribed to to the resource using the watcher's identity.  Further,
the RLS could be authenticated by the presentity using the digest mechanism
and therefore needs to have this capability too.

I would therefore like to know the pitfalls of an RLS not acting as an
authentication service since the same is not configured (both when the
watcher belongs to the RLS domain and does not belong to the RLS domain)
and at the same time not send out back-end subscriptions with the RLS's
identity.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane