Hi,
I had the same problem.
And I think you are right, concerning the branch parameter at Via: headers.
My workaround to overcome this problem :
I use as a branch value the following :
branch=z9hG4bK-[call_number]-XX
(where XX is an index and it's the same for every mesg that the branch value
should be the same).
For example for an INVITE-w-auth scenario, I have the following branch parameter
at Via: lines
- send INVITE
Via: SIP/2.0/[transport]
[local_ip]:[local_port];branch=z9hG4bK-[call_number]-01
- send ACK
Via: SIP/2.0/[transport]
[local_ip]:[local_port];branch=z9hG4bK-[call_number]-01
- send 2nd INVITE (w.auth)
Via: SIP/2.0/[transport]
[local_ip]:[local_port];branch=z9hG4bK-[call_number]-02
- send ACK (for 200 OK response)
Via: SIP/2.0/[transport]
[local_ip]:[local_port];branch=z9hG4bK-[call_number]-03
- send BYE
Via: SIP/2.0/[transport]
[local_ip]:[local_port];branch=z9hG4bK-[call_number]-04
regards,
Kostas
Michael Hirschbichler wrote:
> Hi Group!
>
> Currently I am trying to create an UAC with the following call-flow
>
> UAC Proxy
> INVITE--------------->
> <--------------100 Trying
> <--------------407 Proxy Auth Required
> ACK------------------>
> INVITE (w.auth)------>
> ....
>
> The problem is the ACK-request:
> <send rtd="true">
> <![CDATA[
>
> ACK sip:[EMAIL PROTECTED] SIP/2.0
> Via: SIP/2.0/[transport] [local_ip];branch=[branch]
> CSeq: 1 ACK
> ...
>
> !>
> </send>
>
> By using the [branch]-field as described in the help, I get as a result
> a new branch-parameter "z9hG4bK-1-4", but I _must_ have the same branch
> as in the INVITE:
>
> ====================RFC3261=======================
> 17.1.1.3 Construction of the ACK Request
>
> This section specifies the construction of ACK requests sent within
> the client transaction. A UAC core that generates an ACK for 2xx
> MUST instead follow the rules described in Section 13.
>
> The ACK request constructed by the client transaction MUST contain
> values for the Call-ID, From, and Request-URI that are equal to the
> values of those header fields in the request passed to the transport
> by the client transaction (call this the "original request"). The To
> header field in the ACK MUST equal the To header field in the
> response being acknowledged, and therefore will usually differ from
> the To header field in the original request by the addition of the
> tag parameter. The ACK MUST contain a single Via header field, and
> this MUST be equal to the top Via header field of the original
> request. ...
> ==================================================
>
> Currently, I am planning to use the regexp to parse this parameter.
> Does anyone has a better idea? What about extending the
> [last_...]-feature by creating something like:
> [last_header_field] or [last_header_index_field], like [last_Via_0_brach]?
>
> Best regards
> Michael
>
>
-------------------------------------------------------------------------
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/
_______________________________________________
Sipp-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sipp-users
